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

PDF로 인쇄/내보낼 때 테이블이 렌더링되지 않음

나는 기록 보관소에서 Infobox를 렌더링하지 못한 것에 대해 수다를 떠는 것을 본 적이 있지만, 내가 보기에 문제는 그보다 훨씬 더 광범위하게 퍼져 있는 것 같다.나는 주위를 둘러보았고 내가 확인한 테이블이 있는 모든 WP 기사는 .pdf 인쇄/수출 버전에서 제외된 표를 가지고 있었다.즉, 주위를 둘러본 결과, 인쇄/수출에 의해 생성된 .pdf에 렌더링된 테이블을 아직 찾지 못했다.그렇다, 테이블이 없는 기사들도 많지만, 그럼에도 불구하고 많은 기사들은 기사들에 중요한 정보들을 포함하고 있고, 표로 된 정보 렌더러가 부족하기 때문에 거의 가치가 없다.이는 IMHO가 상대적으로 높은 우선순위를 가져야 한다는 널리 퍼진 문제다.예는 쉽게 찾을 수 있다.

• So Far So Good (Bryan Adams 앨범):§§§ 트랙 목록, 차트 위치 및 인증
• 인구순 국가 및 의존성 목록: § 국가 및 인구순의존성
• 주기율표: § 개요 및 그룹
• 금속, 금속 및 비금속 특성: § 특성 비교
• 오리건: §지리, 주요 도시 및 정치
• 미국 주 약어 목록: § 표
• 해리슨 포드: § 어워드
• 맥컬리 컬킨: § 영화와 텔레비전

당신이 가장 좋아하는 WP 코너로 가서 표를 찾으면 이 버그를 찾을 수 있을 것이다.YBG (대화) 05:08, 2015년 2월 28일 (UTC)

알려진 문제.T73808에 병합된 T87499를 참조하십시오. -- George Orwell III(토크) 06:05, 2015년 2월 28일(UTC)

좋아! 정말 고마워.YBG (대화) 06:16, 2015년 2월 28일 (UTC)

도움말:PDF로 다운로드 -- Gadget850 ^talk 14:49, 2015년 2월 28일(UTC)

인포박스 서브헤더 시프트?

자크 브렐에서 내 눈은 infobox 헤더(Jacques Brel 텍스트가 있는 컬러 막대)가 비대칭이라는 인상을 받는다: 레프탄드 백스페이스는 3px, r8and ws 2px처럼 보인다.나는 지금 파이어폭스 35를 사용하고 있다.관련 가능: #Tables_ just_changed_28using_monobook.29.내 눈만 그런가, 이게 진짜인가? -DePiep (토크) 20:49, 2015년 2월 27일 (UTC)

확실하지 않음, 오늘 드레스가 흰색/금색이었습니까? 아니면 검은색/파란색이었습니까?—DJ (토크 • 기여) 21:33, 2015년 2월 27일 (UTC)

흰색과 금색 팀! --MZMcBride (대화) 22:15, 2015년 2월 28일 (UTC)

자크 브렐에서 내 눈은 infobox 헤더(Jacques Brel 텍스트가 있는 컬러 막대)가 비대칭이라는 인상을 받는다: 레프탄드 백스페이스는 3px, r8and ws 2px처럼 보인다.나는 지금 파이어폭스 35를 사용하고 있다.관련 가능: #Tables_ just_changed_28using_monobook.29.내 눈만 그런가, 이게 진짜인가? -DePiep (토크) 22:13, 2015년 2월 27일 (UTC)

소금에 절인 페이지 위로 이동(축소)

나는 이 실을 되살리고 싶다.

요약:.관리자가 페이지를 소금에 절인 대상으로 옮길 때 페이지가 소금에 절였다는 경고는 없다.(자신이 직접 테스트해 보았는데 아무런 경고도 보지 못했다.표적이 계속 소금에 절여있는지 모르겠다.

사례: [1], [2]

경고 상자가 사용자:네크로테스페는 오래된 AFD를 알고 있다.그러면 그는 새로운 AfD에서 다른 사람들에게 그것을 알게 했을 것이다.

이거 고칠 수 있어?버그 리포트?생각?안나 프로데시아크 (대화) 01:09, 2015년 2월 27일 (UTC)

당신의 q에 "대상물이 계속 소금에 절여있는지 확실치 않다"는 것은 - 소금은 존재하지 않는 페이지의 제목에만 적용될 수 있기 때문이다. 일단 한 페이지가 그 제목으로 이동되면, 그것은 더 이상 존재하지 않는 페이지의 제목이 아니다. --Redros64 (대화) 11:08, 2015년 2월 27 (UTC)

안녕, Redros64.그렇구나. 그리고 또 삭제되면?그러면 비관리자를 위해 레드 링크가 다시 소금에 절이는가?안나 프로데시아크 (대화) 21:51, 2015년 2월 27일 (UTC)

아니, 그렇지 않아. 그리고 방금 User에서 확인했어.암호화/테스트1(토크 내역 링크 감시 로그 편집).—크립틱 22:02, 2015년 2월 27일 (UTC)

고마워, 크립틱그럼, 어떻게 이걸 고칠 수 있을까?이 글이 두 번째 게시물인데, 첫 번째 게시물처럼 무시되고 있는 것 같다.안나 프로데시아크 (대화) 22:06, 2015년 2월 27일 (UTC)

다음 페이지에 게시됨:T91129

안나 프로데시아크 (대화) 22:34, 2015년 2월 27일 (UTC)

사용자 이름 변경, 이제 로그인할 수 없어!!!

나는 에메랄드에서 사용자 이름을 변경해 달라고 요청했다.RS에서 에메랄드위키까지요변경이 진행되었다고 뜨는데 예전 사용자 이름이나 새 사용자 이름으로 로그인할 수 없어.새 사용자 이름으로 계정 이름이 변경되거나 병합된다는 메시지가 표시됨.놓친 게 있어?도움말! 80.176.153.231 (대화) 17:35, 2015년 2월 27일 (UTC)

개명은 한 시간 전 [3]이며, 당신의 계정은 총 1,000개 가까이 수정되었다.나중에 다시 시도프라임헌터 (토크) 17:52, 2015년 2월 27일 (UTC)

기다렸는데, 개명한지 15시간 정도 지났는데 아직도 로그인이 안 되네.단순히 기다리는 문제일 뿐 수리가 필요하지 않은 것이 확실한가? 80.176.153.231 (대화) 08:49, 2015년 2월 28일 (UTC)

지금쯤이면 먹혔어야 했다고 생각해.에메랄드위키로 로그인하려 하면 정확히 어떻게 되는 겁니까?만약 당신이 메시지를 받는다면, 정확하게 그것을 인용하시오.meta: 또는 wikisource:에 로그인할 수 있는가?프라임헌터 (대화) 13:01, 2015년 2월 28일 (UTC)

로그인 오류/ 계정이 현재 이름이 변경되거나 병합되고 있습니다라는 메시지를 로그인하려고 하면, '상태 보기'를 클릭하면 de를 제외한 모든 '완료'와 함께 글로벌 이름 변경 진행률이 표시된다.wikipedia.org은 '대기 중'이며 24시간 가까이 지속되고 있다.메타, 위키소스, 커먼즈에서 정확히 같은 것을 얻는다.나는 드를 사용해 본 적이 없다.wikipedia.org 그리고 독일어는 말할 수 없지만, 아마도 결코 하지 않을 것이다.도와줬으면 좋겠다. 80.176.153.231 (대화) 14:23, 2015년 2월 28일 (UTC)

보아하니 세계적인 명칭 변경 과정이 여전히 de를 기다리고 있는 것 같다.완성될 위키백과.그것이 글로벌 계정의 단점 중 하나이다. 만약 하나의 로컬 인스턴스가 지연되거나 중단된다면, 나는 당신이 당신의 계정을 전혀 사용할 수 없다고 생각한다.독일어 줄이 끝나기를 기다려야 할 것 같아.De728631 (대화) 14:36, 2015년 2월 28일 (UTC)

알았어, 고마워. 기다릴게.나는 전에 내 사용자 이름을 한 번 바꿨는데, 그 때 너무 빨리 일어난 일이라 깜짝 놀랐다. 내 요청을 제출한 지 5분도 안 되어 로그아웃조차 하지 못했다.이번에는 정말, 정말 느리다! 80.176.153.231 (토크) 14:40, 2015년 2월 28일 (UTC)

• @Kegan: 그렇게 긴 지연이 예상되나?–xeno^talk 14:57, 2015년 2월 28일(UTC)
• 2015년 1월 10일에 생성되었지만 아무런 편집도 하지 않은 에메랄드위키라는 사용자가 deWP에 이미 있다는 점에 유의하십시오.그게 새로 개명한 그의 글로벌 계정인가, 아니면 개명을 보류하고 있는 관계없는 계정인가?내가 확인한 몇 개의 무작위 다른 위키에는 esWP가 있지만, 그런 이름의 사용자가 없다.SiBr₄ (대화) 15:15, 2015년 2월 28일 (UTC)

정체성이 확인된 것 같다.DE에 있는 다른 에메랄드위키를 인수하거나, 더 이상 로그인할 수 없다는 것을 염두에 두고 다른 사용자 이름을 선택할 수 있을까?80.176.153.231 (대화) 15:22, 2015년 2월 28일 (UTC) 1월 DE에 있는 에메랄드위키는 나와는 아무 상관이 없다고 말해야 한다.나는 에메랄드였다.RS 또는 이전 사용자 이름. 현명하지 못한 방법으로 본명이 80.176.153.231 (대화) 15:26, 2015년 2월 28일 (UTC)

나는 그 보류 이유를 모르지만 나는 분명히 당신이 에메랄드RS일 때 만들어진 계정이 당신의 계정이라고 생각한다.특수:CentralAuth/Emerald-wiki는 이 계정이 글로벌 계정에 속한다는 것을 보여주며, 다른 위키에서도 사용자가 만들어진 시점에 만들어졌다.다른 wiki에 로그인하고 글로벌 로그인 시스템의 일부인 Wikimedia wiki의 페이지를 방문하면 계정이 자동으로 생성된다. de:특수:로그/Emerald-wiki는 자동 생성임을 확인한다.아마존닷컴은 또한 부가되지 않은 계산은 없다고 말한다.프라임헌터 (토크) 2015년 2월 28일 (UTC) 15:41, 28

그럼 계속 기다릴게!!!나는 독일어를 알고 그들의 도움 회담 중 하나에 대해 질문하기를 바란다!80.176.153.231 (대화) 15:48, 2015년 2월 28일 (UTC)

안녕, ping 고마워, xeno.우리가 고쳐줄게.기다리게 해서 미안해, 그건 정상이 아니야.키건 (WMF) (토크) 03:36, 2015년 3월 1일 (UTC)

완료 - Legoktm이 계정을 잠금 해제하고 문제를 해결하기를 희망한다.당신은 당신의 계정에 로그인할 수 있어야 한다.혹시나 나중에 자물쇠가 잠기는 문제가 있다면 언제든지 나에게 직접 연락해줘.내 연락처는 내 사용자 페이지에서 찾을 수 있어.다시 한 번, 번거롭게 해서 미안해.키건 (WMF) (토크) 03:58, 2015년 3월 1일 (UTC)

여러분 감사합니다, 여러분.오늘 아침에 일어났는데 내가 제일 먼저 시도했던 것은 위키에 로그인하는 거였어. 바로 들어갔어. 문제없어. 대단해!!리처드 에메랄드 (토크) 2015년 3월 1일 10시 41분 (UTC)

AfD 통계 도구가 나에게 표를 인식하지 않음

이것이 AfD에서의 나의 투표가 아닌 나의 유목민들만 세는 이유가 있는가? --Fauzan^{✆ talk}_{✉ mail} 16:04, 2015년 2월 28일 (UTC)

위키피디아에 대한 나의 기여:삭제 조항/* --Fauzan^{✆ talk}_{✉ mail} 16:13, 2015년 2월 28일 (UTC)

어느 표를 말하는 겁니까?나콘 04:02, 2015년 3월 1일 (UTC)

나콘, 내 말은 투표 매트릭스는 내 공천만 보여주고 AFD의 다른 50표들은 안 보여도구가 AfD에서 내 표를 인식하지 못하고 있는데, 그래야 한다. --Fauzan^{✆ talk}_{✉ mail} 08:23, 2015년 3월 1일(UTC)

NCMEC 템플릿

최근 실종아동 및 착취아동센터 링크 템플릿을 만들어 실종자 페이지에 사용했지만 URL이 제대로 작동하지 않는다.템플리트를 보고 만들었는데:무덤을 찾아라.내 템플릿 페이지:템플릿:NCMEC. 여기에 사용된 페이지: Michaela Garecht와 포스터의 URL이 있다. [4].포맷이 웹사이트의 신원 미상의 사람들을 위한 내 템플릿과 완벽하게 작동하기 때문에 누군가가 이 문제에 대해 도움을 줄 수 있기를 바란다(템플릿플릿 참조).NCMEC UID.고마워, --GouramiWatcher^(?) 17:04, 2015년 2월 28일 (UTC)

나는 웹사이트를 모른다.템플릿에 NCMC가 아닌 NCMU라고 두 번째로 기재된 이유가 있는가?NCMC로 변경될 경우 사용 가능한 예. Prime헌터(토크) 17:26, 2015년 2월 28일 (UTC)

"NCMU"는 정체불명의 사람들과 함께 사용된다.실종된 아이들의 URL에는 "NCMC"가 있다. --GouramiWatcher^(?) 20:12, 2015년 2월 28일 (UTC)

그러나 템플릿의 이유는:NCMEC는 작성자, 날짜 또는 액세스 날짜 매개 변수가 있는 경우에만 NCMC가 있는 URL을 선택하고, 없는 경우 NCMU가 있는 다른 URL을 선택하십시오.그러한 변수들 중 어느 것도 그들이 정체불명의 사람들 대 실종된 아이들과 관련이 있는 것처럼 들리지 않는다.매우 이상한 시스템인 것 같고, 접속 날짜가 추가되면 URL을 변경하는 외부 링크 템플릿을 만드는 것은 매우 좋지 않은 생각이라고 생각한다.즉, 사용자가 링크를 테스트하고, 작동하고, 액세스 날짜를 추가할 수 있으며, 사용자가 다시 확인하지 않고 이 링크를 해제할 수 있다.또한 NCMC 케이스가 잘못 코딩되어 있어 수리가 필요하지만, NCMC/NCMU 전체 선택의 이면에 있는 아이디어를 먼저 이해하고 싶다.프라임헌터(토크) 21:51, 2015년 2월 28일 (UTC)

Prime에 따라 NCMU를 NCMC로 변경헌터와 그것은 그 때 포스터를 잘 끄는 것 같지만, 위의 우려는 여전히 핵심이다.

아, 이제 그 전제를 알 것 같은데, 첫 번째 화신은 인라인 레퍼런스를 위한 인용문이고, 두 번째 화신은 독립형 사용을 위한 것이다. (그러나 여전히 앞뒤가 맞지 않는다.) -- 조지 오웰 3세 (토크) 22:03, 2015년 2월 28일 (UTC)

아마 그런 의도일 것이다.두 템플릿의 현재 모든 용도는 외부 링크 섹션에 있으며, 이들 중 어느 것도 첫 번째 화신을 호출하는 매개변수를 사용하지 않는다.OP는 템플릿에 대해 "포맷은 완벽하게 작동한다"고 말했다.NCMEC UID, 그러나 해당 템플릿은 작성자, 날짜 또는 액세스 날짜가 추가된 경우 URL을 변경('=')했다.내가 실험한 모든 경우에서, 이것은 연결 고리를 깨트렸다.단순히 테스트한 적이 없고 NCMU의 변경과 누락된 파이프 추가 외에 두 템플릿의 URL에서 '='를 제거해야 한다고 생각한다.나는 [5][6]을 변경했고, 이제 두 템플릿 모두 두 가지 포획에 대한 작업 링크를 제공한다.

• 국립 미아보호센터 다나 포인트 신원미상 환자
• "Dana Point Jane Doe". NCMEC. Retrieved March 1, 2015.
• 미아보호아동센터 마이클 휴즈
• "Michael Hughes". NCMEC. Retrieved March 1, 2015.

프라임헌터 (대화) 00:52, 2015년 3월 1일 (UTC)

도와줘서 고마워!헷갈린 사람이 있다면 미안해! --GouramiWatcher^(?) 03:30, 2015년 3월 1일 (UTC)

테이블 다음에 무슨 일이 일어날까?

위키피디아와 항상 함께 일하는 사람으로서 나는 패딩의 변화에 매우 불만스럽다.나는 위키피디아에서 일하는 대부분의 시간을 결과표(대부분의 모터스포츠 결과표)에서 작업한다.그 결과 테이블은 꽉 조여야 20개, 때로는 56개 이상의 레이스를 한 테이블에 놓을 수 있다.예: 데이브 마시스.이제 패딩이 바뀌었으니(더빙) 이 결과표들은 필요 이상으로 커진다.이것은 그들을 너무 거칠고 깔끔하게 만든다.패딩이 왜 두 배로 늘었는지 정말 이해가 안 가.이것은 위키피디아의 모든 표에 영향을 미친다.나는 이것이 내가 이 모든 결과표를 만들기 위해 쏟은 모든 노력에 영향을 미친다는 것에 실망하고 화가 난다.다음에 무슨 일이 일어날까?내 말은 패딩이 두 배로 늘어나는 것은 작은 변화가 아니라는 것이다.특히 이것이 위키백과의 거의 모든 표에 영향을 미칠 때.그들이 이 변화를 되돌릴 가능성이 있는가?Jahn1234567890 (대화) 15:59, 2015년 3월 1일 (UTC)

https://phabricator.wikimedia.org/rMW33cfd0bc4a5f009b86c40b0312b4c7f7b006cbc7에서 코멘트를 하셨습니까? --Ahecht (TOKPAGE
) 18:08, 2015년 3월 1일 (UTC)

Qqx를 기본 언어로 사용

우리는 인터페이스 메시지 이름을 얻기 위해 URL에 &uselang=qx를 추가할 수 있지만, 요청을 제출할 때도 인터페이스 메시지 이름을 얻고 싶을 때 우리는 무엇을 할 수 있는가?언어 선택기에서 기본 설정에서 qqx가 보이지 않는다.세나륨 (대화) 2015년 3월 1일 19:50 (UTC)

"요청서를 제출할 때"라니 무슨 뜻이야? 이게 페이지 편집인가?만약 그렇다면, URL은 이미 물음표를 (그러나 반드시 바로 앞에 있는 것은 아님)보다 더 이른 시점에 포함할 것이다.action=edit; 이것들 중 하나만 있을 수 있으니, 그것만 남겨두고, 덧붙이시오.&uselang=qqxURL의 오른쪽 끝에 --Redrose64 (토크) 19:56, 2015년 3월 1일 (UTC)

문제는 표시된 메시지가 현재 URL뿐만 아니라 방금 한 작업(예: 페이지 이동)에 따라 달라지는 경우에 관한 것이다.uselang=qx를 추가한다고 해서 항상 올바른 상황과 메시지가 재현되는 것은 아니다.이러한 상황에서 사용된 MediaWiki 메시지를 찾으려면 위키백과에 다음 팁을 참조하십시오.마을 펌프(기술)/아카이브 131#삭제 성공 후 결과에 사용되는 인터페이스 페이지프라임헌터 (대화)20:52, 2015년 3월 1일 (UTC)

고마워. 그래, 내가 페이지를 옮길 때였어.미디어위키 네임스페이스를 검색할 때 오버레이되지 않은 기본 메시지(사이트 언어 전용, AllMessages)가 색인화된 경우 작업을 쉽게 할 수 있지만 유용한 팁이 몇 가지 있다.세나륨 (대화) 21:55, 2015년 3월 1일 (UTC)

C: 정말이야.Phabricator 입니다.T22858. 만약 당신이 mediawiki/core.git의 복제본을 가지고 있다면, "git grep"이 아마도 가장 빠를 것이다. --MZMcBrid (대화) 22:00, 2015년 3월 1일 (UTC)

보안 링크 아이콘

빨간색 링크의 경우에만 보안 링크 아이콘이 있는 이유: 빨간색 링크 예제 및 보안 로그인. -- Gadget850 ^talk 21:47, 2015년 3월 1일(UTC)

무슨 말인지 잘 모르겠어.내부 빨간색 링크에는 보안 링크 아이콘이 있는 것으로 알고 있다.HTTPS를 통해 Vector 또는 Monobook을 사용하는 빨간색 링크 예제 옆에 아이콘이 표시되지 않음. 설정 또는 스크린샷에 대한 추가 세부 정보를 제공할 수 있는지 확인하십시오. --MZMcBrid (대화) 21:57, 2015년 3월 1일(UTC)

로그아웃된 것을 보지 못한 나인가 보다. -- Gadget850 ^talk 22:13, 2015년 3월 1일 (UTC)

내 JS에 뭔가 있어가능한 사용자:Anomie/링크 분류기. -- Gadget850 ^talk 22:20, 2015년 3월 1일 (UTC)

보안 링크 아이콘이 보이지 않지만 작은 WP:사용자 덕분에 특정 링크에 대한 SKYBLUELOCK:Anomie/링크 분류기.slkndkfoewgfoiwenbgflksgewe와 같이 무작위적으로 생성되지 않은 것은 여기에 어떤 아이콘도 보이지 않는다.Anomie 1 23:27, 2015년 3월 1일 (UTC)

[글로벌 제안] m.Wikipedia.org: (모두) 페이지 편집

미디어위키 모바일

안녕, 이 메시지는 en.m과 같은 도메인에서 너에게 그것을 알려주기 위한 거야.wikipedia.org, 등록되지 않은 사용자는 편집할 수 없음.글로벌 구성 변경이 주로 논의되는 위키미디어 포럼에서는 수십 명의 사용자가 모든 모바일 사이트에 대한 정상적인 편집 권한을 복원하자고 제안한다.읽어보시고 댓글 달아주시죠.

네모 22:32, 2015년 3월 1일(UTC) 영어로 써줘서 고맙고 미안하다.

잘못된 레드링크

Lyndon B에서 뭔가를 확인하고 있었어. 존슨 기사, 그리고 그의 아버지인 사무엘 에일리 존슨 주니어의 연결고리가 빨갛게 되어 있는 것을 보았다.하지만, 내가 링크를 맴돌았을 때, PopUps는 나에게 사실 사무엘에 대한 기사가 있다는 것을 보여주었다.그러나 링크는 빨간색이었고, 나는 여전히 "(페이지가 존재하지 않는다)" 제목 텍스트를 받았다.사무엘 기사는 몇 년 전부터 존재해 왔기 때문에, 최근에 만들어진 글이고 백링크 색상이 아직 바뀌지 않은 그런 상황은 아니다.내가 그 페이지를 숙청했는데, 적어도 나에게는 그것이 문제를 해결한 것 같다.여기 스크린그래프가 있다.이게 알려진 문제인가?나는 페이브리케이터를 훑어보았지만 비슷한 것은 보지 못했다. — PinkAmpers&^{(Je vous invite à me parler)} 02:27, 2015년 3월 2일 (UTC)

Samuel Ealy Johnson Jr.의 페이지 이력은 그것이 Lyndon B의 1분 후에 그 타이틀로 옮겨졌음을 보여준다. 존슨은 마지막으로 편집되었기 때문에, 당시 캐시된 정상적인 레드 링크일 뿐이었다.프라임헌터 (토크) 02:50, 2015년 3월 2일 (UTC)

@PrimeHunter:아, 설명이 되네.눈치 챘어야 했는데.고마워요. — PinkAmpers&^{(Je vous invite à me parler)} 06:21, 2015년 3월 2일 (UTC)

표지판 앱

여러분 안녕하십니까?

당신도 알다시피 안드로이드용 위키백과 표지판 모바일 앱이 있다.현재는 borked이지만, 소스 코드는 GitHub에 있다.우리는 현재 많은 조직적인 작업을 하고 있으며 모바일 앱은 우리가 조사하고자 하는 것 중 하나이다: 우리는 막후에서 기술적 개선을 조사하고 있으며 우리는 기회를 이용하여 모바일 액세스를 사물에 보다 밀접하게 통합하고자 한다.

Android 프로젝트는 곧 고쳐질 것 같다; 누군가 iOS에 Signpost 모바일 앱을 포팅하는 일에 관심이 있거나, 그런 프로젝트에 관심이 있다고 생각하는 누군가를 알고 있을까?ResMar 05:40, 2015년 3월 2일 (UTC)

네임스페이스별로 알림 권한 편집

화장이나 매장?

화장이나 매장 지울 수 없는 이유삭제를 선택하면 페이지를 다시 로드하십시오.다른 페이지는 삭제할 수 있지만 이 페이지는 삭제할 수 없다.케임브리지베이날씨, 우카크투크(토크), 수나스투크 07:28, 2015년 2월 26일 (UTC)

잘 모르겠어.나는 그냥 했고 그것은 잘 작동했다.브라우저나 개인 Javascript에 뭔가 있나?세라핌블레이드 08:11, 2015년 2월 26일 (UTC)

이상하네, 문제없이 다른 페이지를 삭제했네.북극의 거의 모든 것에 대해 비난을 받기 때문에 나는 그것을 태양 흑점에 내려놓을 것이다.케임브리지베이날씨, 우카크투크(토크), 수나스투크 08:19, 2015년 2월 26일 (UTC)

보통 url의 질의 문자열을 나타내는 '?'의 문제인 것 같다.MediaWiki는 혼란을 피하기 위해 페이지 이름에서 '?'를 %3F로 인코딩하지만, 브라우저가 여전히 혼란스러울 수 있다.어떤 브라우저?Coosu vadis도 마찬가지인가?프라임헌터 (대화) 2015년 2월 26일 19시 30분 (UTC)

우분투 14.04에서 크롬 버전 40.0.214.115를 사용 중이었는데, 방금 Firefox 36.0에서 Coosing vadis 페이지에서 시도해 봤더니 같은 결과가 나왔어.이번에 URL을 확인해보니 https://en.wikipedia.org/wiki/Quo_vadis%3F?action=delete이었습니다.나는 나중에 윈도우에 도전해 봐야겠다.케임브리지베이날씨, 우카크투크(토크), 수나스투크 23:01, 2015년 2월 26일(UTC)

@캠브리지베이날씨:이상하네, 크롬 40.0.22214.111과 함께 우분투 14.10을 사용하고 있으니까.트윙클이나 다른 스크립트를 사용하십니까? 아니면 일반 미디어위키 삭제 버튼만 사용하십니까?세라핌블레이드^{Talk to me} 01:22, 2015년 2월 27일 (UTC)

그것은 정말로 '?'와 관련된 문제지만 아마도 당신의 브라우저에서는 그렇지 않을 것이다.너의 링크 https://en.wikipedia.org/wiki/Quo_vadis%3F?action=delete은 나에게도 통하지 않아.그 고리에 어떻게 도달하고 당신의 피부는 무엇인가?벡터에 있는 "추가" 탭을 클릭한 다음 "삭제"를 클릭하십시오.그것은 나에게 효과가 있는 https://en.wikipedia.org/w/index.php?title=Quo_vadis%3F&action=delete을 준다.당신의 URL 구조는 https://en.wikipedia.org/wiki/Quo?action=delete과 같이 '?'를 포함하지 않는 페이지 이름에서 작동한다.https://en.wikipedia.org/wiki/...%3F 형식의 URL에 쿼리 파트를 추가할 수 없는 것은 MediaWiki 버그일 수 있다.비관리자가 테스트할 수 있기 때문에 https://en.wikipedia.org/wiki/Quo_vadis%3F?action=history의 경우에도 실패한다."역사 보기" 탭에는 https://en.wikipedia.org/w/index.php?title=Quo_vadis%3F&action=history이 나오는데, https://en.wikipedia.org/wiki/Quo?action=history도 https://en.wikipedia.org/wiki/Quo?action=history처럼 작동했어야 한다고 생각한다.미디어위키는 %3F가 인코딩된 '?' 페이지 이름을 끝내는 '?'와 '?'가 쿼리 파트의 시작인 %3F? 조합을 외치는 것으로 보인다.아니면 내가 모르는 일반적인 url 규칙이 있을지도 몰라. url's에 어떤 '%3F?'가 허용되지 않는지.프라임헌터 (대화) 01:49, 2015년 2월 27일 (UTC)

%3F? 조합은 이 wiki에서 이전 MediaWiki 버전인 http://mersennewiki.org/index.php/Why_participate_in_GIMPS%3F?action=history에서 작동한다.http://mersennewiki.org/index.php/Special:Version에 따르면 미디어위키는 1.5.8. 프라임헌터 (토크) 02:24, 2015년 2월 27일 (UTC)

문제는 페이지 이름 끝에 '?'로 제한되지 않는다.아마존닷컴은 Nycticebus 언어의 페이지 기록을 만들었어야 했다.프라임헌터 (토크) 02:56, 2015년 2월 27일 (UTC)

사용자:프라임헌터.작동되지 않는 링크를 얻기 위해 나는 원래의 Coosu vadis를 따라갔다.당신이 제공한 링크.그리고 나서 삭제를 클릭했고 그것은 https://en.wikipedia.org/wiki/Quo_vadis%3F?action=delete not working 링크와 함께 페이지를 다시 로드했다.벡터도 쓰고 있어.당신이 "More" 탭을 클릭한 다음 "Delete"를 클릭했다는 것을 알 수 있다."More"에서 유일한 옵션은 "Purge"이다.삭제 선택사항은 "페이지" 탭에 있으며 "페이지 삭제"라고 되어 있다.또한 https://en.wikipedia.org/w/index.php?title=Quo_vadis%3F&action=delete은 나에게도 효과가 있다.나는 나의 삭제 일지를 훑어보았고, 이것을 발견했고, 마지막에 적어도 하나가 더 있고, 중간에 하나가 더 있는 것을 보았다.그래서 한때 나는 마지막에 ?가 있는 페이지를 삭제할 수 있었다.너의 01:49 게시물에 있는 다른 링크는 모두 내가 너에게 했던 것과 똑같이 작용한다.케임브리지베이날씨, 우카크투크(토크), 수나스투크 03:19, 2015년 2월 27일 (UTC)

"페이지" 탭은 MediaWiki의 일부가 아니다.특수:의 "페이지 및 사용자 드롭다운 메뉴를 도구 모음에 추가"로 작성:기본 설정#mw-prefection-gadgets.이 가젯은 기본적으로 비활성화되어 있다.나는 그것을 활성화하고 페이지 탭의 당신과 동일한 비작업 URL을 얻으려고 노력했다.이 가젯은 MediaWiki:MediaWiki를 사용하는 Gadget-dropdown-menus.js:Vector 사용자를 위한 가젯 드롭 다운-메누스-벡터.js. 그러나 버그는 MediaWiki에 있고 거기서 고쳐져야 한다.페이지 이름의 물음표는 드물고, url's를 사용하여 버그 주변에서 작업하도록 기기를 코딩할 가치가 있는지 확실하지 않다./w/index.php?title=대신에/wiki/. 프라임헌터 (대화) 03:33, 2015년 2월 27일 (UTC)

그래, 바로 그거야.나는 가젯을 제거했고 https://en.wikipedia.org/w/index.php?title=User:CambridgeBayWeather/Test3%3F&action=delete을 삭제할 수 있었다.나는 가젯이 활성화되면 페이지를 이동시키고 리디렉션을 남기지 않는 것이 가능하다는 것을 알았다.그것은 ? 페이지를 삭제했고 물론 나는 ?, https://en.wikipedia.org/w/index.php?title=User:CambridgeBayWeather/Test%3F&action=edit&redlink=1 없이 페이지를 삭제할 수 있었다.이 가젯에 대해 내가 좋아하는 점이 몇 가지 있고 ?가 나오는 아주 몇 번을 고려하면, 나는 이 장치를 활성화한 채로 이삿짐 해결 방법을 사용할 것이다.그 동안 감사했습니다케임브리지베이날씨, 우카크투크(토크), 수나스투크 03:48, 2015년 2월 27일(UTC)

이동은 쿼리 문자열이 아닌 특수 페이지로 이루어지기 때문에 버그가 간섭하지 않는다.페이지 탭의 보호 및 제거가 영향을 받는다.그것은 아마도 몇몇 다른 스크립트들과 도구들에도 영향을 미칠 것이다.나는 파브리케이터에 능숙하지 못하다.거기 있는지 누가 보고, 없으면 추가할 수 있어?프라임헌터 (대화) 04:18, 2015년 2월 27일 (UTC)

페이지 탭의 보호에 문제가 있는 것 같지 않아.어제는 잘 되었다.케임브리지베이날씨, 우카크투크(토크), 수나스투크 04:58, 2015년 2월 27일(UTC)

물음표가 있는 페이지 이름에서?그 벌레는 단지 그것에 영향을 미치는 것으로 알려져 있다.프라임헌터 (대화) 05:11, 2015년 2월 27일 (UTC)

MediaWiki에 대해 해결할 수 있는 기능:가젯-드롭다운-메뉴-벡터.js. 하지만 나는 당신이 사용하는 것이 비벡터 버전이라면 유지하지 않는다.같은 버그 때문에 페이지 이름과 관련된 모든 내부 링크가 작동하지 않을 것이므로, 내가 생각하는 중간 기간 동안 수정할 가치가 있다.— 뮤지크애니멀 06:23, 2015년 2월 27일 (UTC)

지금 고쳐야 한다.보고해줘서 고마워! — 2015년 2월 27일 07:05, (UTC

하지만 이건 핵심으로 고쳐야 해... -- [[User:Edokter]] {{talk}}2015년 2월 27일 12시 38분(UTC)

감사 사용자:지금 작동하는 뮤지크 애니멀.케임브리지베이날씨, 우카크투크(토크), 수나스투크 16:18, 2015년 2월 27일(UTC)

• @MusikAnimal:벡터를 사용하는데 앰퍼샌드와 따옴표도 같은 문제를 겪고 있다.이 토론을 참조하십시오.--Bbb23 (대화) 09:20, 2015년 3월 3일(UTC)

검색이 업데이트되지 않음

일반적으로 10-15초 이내에 업데이트되는 CirrusSearch는
12.37과 12.38에서 "수신"의 오타를 수정했지만, 거의 6시간 후 수신을 위한 검색에서 양쪽 실이 모두 나타난다 - Arjay (토크) 18:18, 2015년 3월 1일 (UTC)

하루에 한 번 업데이트 되는 줄 알았는데, 8시간 정도 쉬는 UTC 04:00경. --Redros64 (토크) 19:59, 2015년 3월 1일 (UTC)

옛 루세네 검색은 하루에 한 번 업데이트된다.현재 CirrusSearch는 일반적으로 훨씬 더 빨리 업데이트되어야 한다.mw: 참조도움말:CirrusSearch#Updates.나는 또한 현재 당신의 diff의 오래된 수정본을 받는다. (동일한 diff를 두 번 게시하셨습니다.)프라임헌터 (대화) 21:01, 2015년 3월 1일 (UTC)

이것은 LuceneSearch 지수가 업데이트되지 않았을 때보다 더 심각하다; 적어도 그것이 다시 시작되었을 때, 일주일이 걸리더라도, 그것은 모든 것을 완전히 재색인화 할 것이다.내 생각에 CirrusSearch 업데이트 실패는 이 정도까지는 발견되지 않았고, 일을 바로잡기 위해서는 뭔가 특별한 조치가 취해져야 할 것이다.이런 일이 실제로 일어날 수 있으리라고는 기대하지 않았던 것 같고, 빨리 고칠 수 있는 방법이 있다면 놀랄 것이다.철자공^yack 크리스 21:23, 2015년 3월 1일 (UTC)

우리는 가동 중단에 대처하기 위한 대본을 가지고 있다.그것은 내가 처음 지은 것 중 하나이다.네베렛 (WMF) (대화) 2015년 3월 2일 (UTC) 18:21, 2

페이브리케이터로 파일 작성:T91216. --MZMcBride (대화) 21:31, 2015년 3월 1일 (UTC)

난 방금 패브릭레이터를 신청했어T91217, 그리고 당신의 글을 보았다.네가 내 코를 한 대 때린 것 같아.나는 내 것을 너의 복제품이라고 업데이트 할 것이다.크리스 더 스펠러^yack 2015년 3월 1일(UTC)

이제 기사가 편집되면서 지수에 대한 업데이트는 다시 일어나고 있지만, 이미 불평했던 업데이트는 내가 이전에 올린 글처럼 여전히 지수에 업데이트되지 않고 있다.크리스 더 스펠러^yack 02:05, 2015년 3월 2일 (UTC)

일부 오래된 편집은 업데이트된 검색에서 나타났고, 일부는 그렇지 않았다.12.37에 위에 언급된 진짜 글은 아직 없지만, 12.38에 게시했어야 하는 글은 그 이후로 두 글 모두 수정되지 않았다.아직 업데이트되지 않은 기간이 확실한 경우, 해당 기간 동안 편집된 모든 기사를 null 편집하여 검색을 진행하는 것이 가능한가? - Arjayy (토크) 16:36, 2015년 3월 2일 (UTC

그 일을 맡았으니 지금 바로 착수할 것이다.신고해줘서 고마워!우리는 그것을 처리할 대본이 있고 나는 그것을 먹일 타임스탬프를 찾으면 바로 그것을 시작할 것이다.네베렛 (WMF) (대화) 2015년 3월 2일 (UTC) 18:21, 2

나는 내가 모든 영향을 받은 페이지를 재색인화했다고 믿는다.다른 880개 위키에서 이 과정을 시작하려고 해!네베렛 (WMF) (토크) 02:07, 2015년 3월 3일 (UTC)

흠, 나는 놀랐어; 그들은 실제로 그것을 빨리 고칠 수 있는 방법을 가지고 있었어.어제 업데이트 내용을 샘플로 재색인해서 봤는데 다 잡은 것 같아.이것은 내가 예상했던 것보다 더 잘 되었고, 나는 이전보다 더 많은 CirrusSearch 그룹에 대한 믿음을 가지고 있다.해결해줘서 고마워.크리스 더 스펠러 02:56, 2015년 3월 3일 (UTC)

기울임꼴에 대한 질문

나는 Vytautas Mažulis라는 기사를 우연히 접했고 전기 섹션의 이탤릭체가 제대로 표시되지 않는다는 것을 알아차렸다.조직명 '밀란어학회'는 완전히 이탤릭체는 아니지만, 그 이름을 따르는 나라와 구절은 왠지 이탤릭체로 되어 있다.코드가 정확해 보인다.내가 놓친 게 있나?어떻게 이탤릭체를 고칠 수 있을까?마밀레스 (대화) 2015년 3월 2일 16:15, 2 (UTC)

'밀라네세' 이후 인위적인 라인 브레이크가 있었기 때문이다.내가 고쳤지(MOS에 따라 어차피 이탤릭체로 표기하면 안 되겠지만):ILT. 안녕하십니까, 오렌지 스웨이드 소파 (토크) 2015년 3월 2일 (UTC)

좋아 보이네, 고마워.이렇게 하면 내 브라우저가 편집 창에서 "Milanese" 다음에 공백을 표시하지 않는 이유도 정리된다.

나는 책을 읽으면서 이 문제에 대해 신경이 쓰였고, 이탤릭체가 있는지 없는지 신경 쓰지 않았다.그들이 부적절하다고 생각되면 자유롭게 제거해라.마밀레스 (대화) 2015년 3월 2일 16:33, 2 (UTC)

글머리 기호 표시 안 함 목록 내에서 글머리 기호 목록 수정

이것은 기본적으로 미디어위키토크의 재게시 입니다.Common.css#게스트되지 않은 목록 내의 글머리 기호 목록 수정 더 많은 주의를 끌기 위해.

{{unbulleted list}} 내부 {{unbulleted list}} 사용 시 내부 목록에서 해당 상속을 되돌릴 수 있는 수단 없이 {{unbulleted list}} 클래스를 외부 목록에 추가하기 때문에 작동하지 않는다.좀 덜 복잡하게 만들기 위해, 내부 목록이 스타일을 이어받지 못하도록 외부 목록의 직접 하위 항목에 엄격하게 적용할 것을 제안한다.

예:

{{unbulleted list 이 {{bulleted list E F}}}}}

티모시 G. (대화) 03:50, 2015년 3월 3일 (UTC)

댓글이 달렸네. -- [[User:Edokter]] {{talk}}09:46, 2015년 3월 3일 (UTC)

고아 태그가 표시되지 않음

템플릿에 문제가 있음:고아, 편집 요약을 보면: [7] 정리 태그를 숨겼고 그 결과 99개의 기사 중에서 그 태그가 사라졌다.해결 방법이 있는가? - Knowledkid87(대화) 04:53, 2015년 3월 3일(UTC)

@Knowledkid87: 템플릿을 참조하십시오.템플리트가 현재 및 전월(예: 신사의 키스에서는 보이지 않음)에만 표시되지만 {{복수 문제}(예: AUKcon에서 볼 수 있음) 내에서 항상 표시된다는 것을 설명하는 고아#가시성.그 기사들은 여전히 분류되어 있고 여전히 너의 보고서에 실려 있다.템플릿 지침에는 관심 있을 수 있는 수정사항도 포함되어 있다.행운을 빈다!GoingBatty (토크) 05:49, 2015년 3월 3일 (UTC)

대체하지 않는 변전소

내가 여기서 뭘 망치고 있는 거지?마르틴 호크스트라 (대화) 2015년 3월 3일 10시 19분 (UTC)

내부 변위 장치가 작동하지 않음<ref>또는 다른 파서 태그. -- [[User:Edokter]] {{talk}}10:25, 2015년 3월 3일 (UTC)

고맙다! 살아서 배워라.마르틴 회크스트라 (대화) 10:28, 2015년 3월 3일 (UTC)

위키다타 문제

기존 품목에 P527(이름 = '부분이 있다', 값 = 바랑게이)을 (Q316370) 산타페, 세부(이름 = '퀀티', 값 = 10)에 새로 추가한 후 적격자 P1114(이름 = '퀀티', 값 = 10)를 추가했다.

검색하려고 할 때 {{#invoke:Wikidata getRawQualifierValue P527 P1114 FETCH_WIKIDATA}}:
모듈의 루아 오류:168행의 위키다타: '콘카트'에 대한 표의 색인 1에서 유효하지 않은 값(테이블)

나야, 아니면...?

NB 이전에 한정자 값 가져오기(예: {{인구조사 산문})를 성공적으로 사용해 왔다.

--버터링되지 않은 파스닙(토크) mytime=sun 16:35, 위키타임=08:35, 2015년 3월 1일 (UTC)

나는 루아에 대해 잘 모르며 위키다타를 잘 모르기 때문에 틀릴 수도 있지만 내가 보기엔 모듈의 getRawQualifierValue처럼 보인다.Wikidata는 데이터 유형의 한정자를 처리할 수 없음 Wikidata와 같은 수량:속성:P1114. {{인구조사 산문}}은(는) wikidata에 getRawQualifierValue를 사용한다.속성:데이터 유형이 항목인 P459.프라임헌터(토크) 15:58, 2015년 3월 1일 (UTC)

글쎄, 그것은 내가 그 부동산에 한정자를 추가할 수 있게 해 주었으므로, 그것이 작동하지 않는 것이 놀랍다(실제로 우리가 이야기하고 있는 것은 이것이 위키다타다).나는 내 문제를 위키다타 마을 펌프(T)에 맡겨야겠다.버터가 없는 파스닙(토크) mytime=월 07:38, 위키타임=23:38, 2015년 3월 1일(UTC)

모듈에서 문제가 발생한 것 같다.Wikidata 및 Module Talk에 게시:위키다타 입니다프라임헌터 (대화) 23:42, 2015년 3월 1일 (UTC)

나는 위키백과 루아 모듈의 "위키다타"라는 이름을 짓는 것이 혼란을 야기하고 있다고 생각한다.위키다타에서 무슨 일이 일어나든 루아 모듈(Wikidata에서 위키백과로 데이터를 유연하게 가져오기 위한 것)이 항상 작동한다고 보장하지는 않을 것이다.문제는 이 모듈이 Wikidata에 숫자 데이터 유형이 존재하기 전에 작성되었기 때문에 발생한다.라인 168은 해당 한정자에 대한 모든 값의 표를 취하며, 값이 문자열이라고 가정하는 쉼표+공간 구분 기호로 이들을 함께 연결한다.내가 이해한 바로는, 불행히도 table.concat() 방법을 사용하여, 그렇게 숫자를 연결시킬 수는 없다.wikitxt가 숫자를 문자열로 표현하도록 함으로써 문제를 해결할 수 있다고 생각하지만, 확실히 하기 전에 몇 가지 테스트를 해야 할 것이다. --RexS (토크) 00:03, 2015년 3월 2일 (UTC)

조사해줘서 고마워.이상하게도 위의 편집 [8]의 수정 시간은 정상 4로 이루어진 23:42 서명 후 4분 후인 23:46으로 되어 있다.~~~~편집하는 데 약 1초가 걸리고 서명 시간과 수정 시간이 서로 다른 단계에서 기록되어 1분 가까이 변경될 때 저장되는 1분 정도의 차이가 나는 경우가 있다.나는 1분 이상 본 적이 없다.세이브는 빠르게 통과했다.내 브라우저 기록에 따르면 정확한 시계가 23시 46분이었다.프라임헌터 (대화) 00:08, 2015년 3월 2일 (UTC)

글쎄, 내가 생각했던 문제는 아니야.table.concat()은 숫자들을 문자열로 암묵적으로 주조하는 것처럼 보이므로, 연결 방법은 필요한 대로 작용한다.네가 주는 오류 메시지로부터, 나는 이제 테이블의 첫 번째 항목이 실제로 하나의 값이 아니라 테이블이 아닌가 하는 의심이 든다.가서 확인해보고 고칠 수 있는지 알아볼게. --RexxS (대화) 00:24, 2015년 3월 2일 (UTC)

업데이트: 예, 첫 번째 항목은 테이블이므로 호출 시 ", "와 연결할 수 없음. --RexxS (대화) 14:40, 2015년 3월 2일 (UTC)

이것을 보면 볼수록, 복수의 값의 가능성 때문에, 주어진 재산과 연관된 주어진 한정자의 값만 가지고 오라는 일반적인 호출을 쓸 수 없다는 확신이 생긴다.예를 들어 리처드 버튼(d:Q151973)을 보면 3명의 배우자(P26)가 나열돼 있는데, 이 중 2명은 출발시간(P580)과 종료시간(P582)에 대한 예선을 갖고 있다.리차드 버튼의 배우자의 시작 시간 반환을 요청하는 전화는 어떻게 해야 하는가?그것이 엘리자베스 테일러에게 영을 돌려주어야 하는가?아니면 샐리 버튼에게 1983년 7월 3일인가?아니면 1949년 시빌 크리스토퍼에게?물론 우리는 그것이 1949년과 1983년 7월 3일을 반환하도록 할 수 있지만, 그들이 어떤 배우자를 언급했는지 알지 못하는 상태에서 그들은 어떤 가치가 있을까?예를 들어, 첫 번째 주어진 속성에서 첫 번째 주어진 한정자의 값을 가져오는 호출을 작성하는 것은 가능하지만, 그것은 해당 속성에 다른 값을 추가하는 누군가에게 취약해진다.산타페(d:Q316370)가 30개의 시티오를 갖고 있는데 누군가가 "양수=30"이라는 한정자로 "part=sitio"를 추가한다면 어떻게 대처하고 싶으세요?getRawQualifierValue P527 P1114를 10 또는 30으로 반환해야 하는가?문제에 대해 부정적이어서 미안하지만 일반적인 해결책이 보이지 않아. --RexxS (대화) 14:40, 2015년 3월 2일 (UTC)

나는 이 모든 것을 이해할 수 없다.예를 들어 '인구'와 같은 다른 속성은 두 개 이상의 다른 한정자('날짜'와 '방법')를 갖는 것에 매우 만족한다.예를 들어, '인셉션'과 같은 다른 특성은 둘 이상의 가치를 갖는 것에 만족한다.나는 재산의 인스턴스화에 첨부된 한정자를 반환할 수 없다는 것을 믿을 수 없다. 여기서 '부분이 있다'=바랑게이에 첨부된 '양'이다.모든 것을 bin으로 하고 SQL, 또는 어떤 소유물이고 증명된 것에서 다시 시작할 시간.-- 버터 없는 파스닙(토크) mytime=월 23:30, wikitime=15:30, 3월 2일 (UTC)

여러 값을 어떻게 할 것인가에 대한 논의가 필요할 수도 있지만(발신자가 원하는 값을 지정하지 않은 경우 오류 메시지와 추적 범주) 적어도 하나의 값만 있을 때 값을 주도록 코딩될 수 있는가?프라임헌터 (대화) 16:03, 2015년 3월 2일 (UTC)

둘 이상의 한정자를 원하는 경우 지정할 수 있는 방법이 없다. 단지 모든 한정자를 얻을 뿐이다.그러나 한정자는 여기서 암시하는 대로 속성 이름에 붙이지 말고 속성 값에 붙여야 한다.버터가 없는 파스닙(토크) mytime=Tue 00:24, 위키타임=16:24, 2015년 3월 2일(UTC)

그렇다, 주어진 속성과 연결된 모든 문장 중 하나의 한정자가 존재하는 경우, 주어진 한정자의 값을 반환하기 위해 코드를 쓸 수 있다.하지만 만약 누군가가 위키다타에서 또 다른 한정자를 추가한다면 위키백과에서 어떻게 행동하기를 원하십니까?더 이상 독특한 가치가 아니기 때문에 사라져야 하는가?아니면 위키백과 기사에 나오는 두 번째 한정자의 가치를 이전에 독특한 한정자의 가치 대신에 위험을 감수할 용의가 있는가?

한정자는 특정 이름-값 쌍에 확실히 부착되어 있다.그래서 리처드 버튼의 경우, "시빌 크리스토퍼"라는 값을 가진 "스파우스"라는 이름의 부동산이 '1949'라는 값을 가진 "시작일"이라는 한정자를 붙였다.하지만 한정자 값만 반환하는 통화를 원하신다면 어떻게 도움이 되십니까?전화를 걸 때 "시빌 크리스토퍼"의 가치를 모르기 때문이다.반면에, 만약 당신이 있을 때 주어진 한정자의 값 목록과 함께 주어진 특성의 모든 값의 목록을 반환하는 전화를 원한다면, 그것은 Richard Burton / property='spouse' / quarantifier='start date'에 대해 이렇게 보일 수 있기 때문에 가능하다.

• 엘리자베스 테일러; 샐리 버튼, 1983년 7월 3일; 시빌 크리스토퍼; 1949; (엘리자베스 테일러와 버튼의 두 결혼 날짜는 언제든지 추가될 수 있다는 점에 유의한다)

그러나 그것은 Unbuttered Parsnip이 요약한 문제와는 다르다. --RexxS (대화) 22:56, 2015년 3월 2일 (UTC)

'인셉션'이나 '익명'에서처럼 이미 한정자에 대해 둘 이상의 값을 반환한다.나는 심문할 수 없는 방대한 데이터베이스를 제공하는 것이 무슨 의미가 있다고 생각하지 않는다.속성 한정자에 값을 추가할 수 있다면 다시 읽어볼 수도 있어야 한다.특정한 경우에 관해서, 나는 한정자가 둘 이상의 '양' 값을 가질 수 있다는 생각을 전혀 이해할 수 없다.일반적인 경우라면 최신 정보를 원할 것 같다.그래서 보통 10년 전의 인구조사가 아닌 최신 인구조사를 원할 것이다.예외적으로 당신은 그들 모두를 원할지도 모른다.데이터 정렬은 파서 함수가 아니기 때문에 정렬된 목록을 반환하는 것은 WD에 의무적으로 있어야 한다. -- 버튼이 없는 파스닙(토크) mytime=Tue 10:52, wikitime=02:52, 2015년 3월 3일(UTC)

(1) 데이터베이스는 조회할 수 있다. (2) 데이터를 다시 읽을 수 있지만, 검색 기준을 충족하는 복수의 값이 있는 경우, 읽고 싶은 것을 지정해야 한다. (3) 속성이 동일한 한정자의 여러 인스턴스를 가질 수 없는 이유는 전혀 없다.나는 이미 리처드 버튼이 두 번째 아내와 결혼하는 예를 두 번 드렸으니 결혼의 시작일은 1964년과 1975년의 두 가지 다른 가치를 지닌 두 번의 예선전으로 나타날 것이다.리처드 버튼과 엘리자베스 테일러의 결혼 시작일을 부른다면, 어떤 한정자 값을 반환하고 싶으십니까? (3) 날짜뿐만 아니라 숫자나 텍스트가 될 수 있는 모든 한정자 값에 대해 "최신"은 일반적으로 이치에 맞지 않는다. (4) 예, 때때로 여러 개의 한정자 값 중에서 하나의 한정자 값만을 원하는 경우도 있고, 그 방법 또한 없다.어느 것을 원하는지 특정 - 그리고 때로는 모든 것을 원하지만, Wikidata 항목을 다루는 일반적인 모듈을 쓰는 것은 당신이 원하는 것을 할 수 없다. (5) 현재 mw에 대한 호출은 없다.정렬된 테이블을 반환하는 위키베이스 API, 그러나 정렬은 루아 모듈에서 할 수 있으므로 파서 기능은 무관하다. --RexxS (talk) 03:59, 2015년 3월 4일 (UTC)

나한테는 눈엣가시로 읽힌다.우리가 받은 유일한 모듈이 제대로 작동하지 않는 것 같아서 어떻게 데이터베이스를 조회할 수 있을지 모르겠어.특히, 어떤 부동산의 발생이나 어떤 한정자의 발생에 대한 규격을 허용하지 않는다.당신의 답변은 재산의 다른 인스턴스화에 대한 예선이 함께 뒤섞여 있고, 그것이 반환되는 것은 솥뚜껑이라는 것을 암시한다.사실이라면 슬프다.나는 모든 한정자를 특정하지 않았다. 나는 내 자신을 '양'으로 제한하고 있었다.만약 어떤 부동산에 '양'이라는 한정자가 있다면, 나는 두 가지 이상의 관련 가치가 있을 수 있다면 매우 놀랄 것이다.그것은 한정자의 가치가 알려진 모든 숫자를 포함하고 있다고 말하는 것과 같다.차별화 방법이 없기 때문에 단순히 가치를 바꾸는 것이 아니라 한정자의 인스턴스화를 하나 더 추가해서 원시 가치를 업데이트하는 사람이 있을 거라고는 상상할 수 없다.말했듯이, '인셉션'과 같은 다른 속성들은 한정자의 여러 부(날짜)를 허용하고 이를 어기지 않고 돌려준다.
Burton-Taylor와 관련하여, 그들이 두 번 결혼했을 때, 둘 이상의 날짜를 가진 결혼식 튜플이 하나만 있는 것은 잘못된 것 같다 – 정확한 형태는 각 결혼에 대해 하나의 튜플일 것이다. -- 버터 바르지 않은 파스닙 (토크) mytime= Wed 12:49, wikitime= 04:49, 2015년 3월 4일 (UTC)

만약 내가 특정한 목적을 위해 더 많은 모듈을 쓰기를 원한다면, 얼마든지 물어봐라, 하지만 이 모듈들은 여러분과 나 같은 자원 봉사자들에 의해 만들어졌고, 그 누구에게도 "어떤" 자격이 없다는 것을 이해해주길 바란다.Wikidata 모듈을 쓸 때, 그것은 한정자가 아직 개발 중이었기 때문에 단지 재산가치를 가져왔을 뿐이다.그 이후로, 다른 사람들은 내가 지적했듯이, 그들이 어떤 상황에서 일한다는 것이 기쁘지만, 모든 사건을 다룰 수는 없는 예선전을 준비하라는 전화를 추가했다.속성을 가져오려면 해당 속성과 관련된 모든 값을 검색하여 목록(또는 단일 값 또는 nil)의 형태로 반환하면 된다.속성과 연관된 특정 한정자의 값을 가져오려고 하는 경우, 한정자 값만으로 구성된 목록을 만들 때 해당 한정자가 속성에 대해 여러 값이 있어야 하는지 알 수 없다.Re Burton-Taylor, 복수의 한정자를 가진 단일 재산 가치로 배우자 데이터를 조직하는 것에 대해 "잘못된" 것은 없다 - 사실 당신이 Burton의 아내들의 이름으로 infobox를 채울 때 꼭 필요한 것이다.위키다타는 편집자들이 자신이 선택한 방식으로 입력된 데이터를 어느 정도 자유롭게 정리할 수 있도록 하고, 그 데이터를 위키백과로 가져오려는 사람은 누구나 도전해야 할 것은 가능한 모든 경우를 만족시키는 것이다. --RexS (대화) 13:30, 2015년 3월 4일 (UTC)

세션 시간 초과에 걸리는 시간은?

Javascript에서 실행 중인 봇에 문제가 있어 사용자로 로그인하여 완료하는 데 3~4시간 정도 걸리는 많은 작업을 한 후 최종 결과를 편집한다.마지막에는 편집에 대한 오해가 오는데 (최근까지 받지 못했는데, 사실..내 유일한 추측으로는 봇이 자동으로 로그아웃되는 데 시간이 오래 걸려서야 끝날 수 있다는 것이다.'로그인 유지' 버튼을 선택한 상태로 한 번 더 시도해보려고 하는데, 정보를 위해서라면 세션 제한시간을 아는 사람 있어?사용자가 직접 설정을 수정할 수 있는 방법이 있는가?최근, 즉 최근 몇 주 동안 디폴트 값이 변경되었는가?고마워!---두드만펠라브라 (대화) 01:19, 2015년 3월 3일 (UTC)

OK 나는 코드를 다시 실행했고 "로그인 유지" 버튼을 선택했음에도 불구하고 같은 오류를 얻었고, 그래서 나는 지금 난처해졌다.실행 후 로그아웃이 되지 않았는지 확인하기 위해 에러 후 다른 페이지를 방문했는데 아직 충분히 로그인되어 있는지 확인했기 때문에 문제가 되지 않는 것 같다.

코드는 봇 1(사용자:NationalRegisterBot) 및 이 개인용(대부분 이와 같은 상황용)개인 계정으로 로그인하는 동안, 나는 단지 3-4시간 대신 실행하는데 10분 정도밖에 걸리지 않지만 페이지를 편집하기 위해 동일한 루틴(문법적으로 동일한 자바스크립트 기능)에 의존하는 코드의 더 작은 부분을 실행하려고 노력했고, 그것이 작동했고, 그것이 예정되어 있던 페이지를 성공적으로 편집했다.이것은 아마도 봇 계정의 토큰을 가져오는 데 문제가 있었을 것이라고 믿게 만들었고, 그래서 나는 내 봇 계정에 로그인하는 동안 내 개인 계정에 작용하는 것과 같은 기능을 실행하려고 시도했지만, 놀랍게도, 효과가 있었다!

다시 말하지만, 작동했던 코드 조각과 원래 3-4시간 코드 조각은 같은 루틴에 의존하여 마지막에 페이지를 편집한다...연습에 있어 두 기능의 유일한 차이점은 두 기능이 실행되는 데 걸리는 시간이다.3~4시간 코드는 실행 시간이 너무 오래 걸리기 때문에 편집 토큰으로 뭔가 기겁을 해서 무효가 되는 것 같다.편집 토큰이 만료되었거나 그런 경우인지 알아보기 위해 실행 시작 시 편집 토큰을 가져온 다음 실행 종료 시 다시 한 번 코드를 만들어 두 가지를 비교하고 두 가지를 모두 동일한 출력을 얻었다(42163ed75d03ff490b30c96e9d59716a5440f+\).같은 내용이었기 때문에 토큰이 집행 과정에서 만료되는 것으로 보이지 않아 정말 난감하다.어떻게 기능이 다른 인스턴스에서는 작동하지 않고 다른 인스턴스에서는 작동하지 않을 수 있는가?

이 모든 것이 약 2~3주 전부터 시작되었으므로 API나 다른 곳에서 뭔가 바뀐 것이 아닌가 하는 의심이 들지만, 그것에 대한 정보는 전혀 찾을 수가 없었다.내가 설명하는 오류가 발생하는 이유를 아는 사람?--Dudemanfellabra (대화) 08:59, 2015년 3월 3일 (UTC)

실행 시작과 종료 시 편집 토큰을 가져오는 테스트는 매번 동일한 토큰을 제공하지 않아야 하며, 1초 간격으로 두 토큰을 가져오더라도 10월 말부터 두 개의 다른 토큰(두 토큰 모두 유효함)을 제공해야 한다.같은 토큰을 몇 시간 간격으로 받았기 때문에 토큰을 가져오는 데 사용하는 것은 두 번째 토큰을 가져오는 것보다 캐싱하는 것이 분명하다.

이상적으로는 당신의 봇이 편집을 시도할 수 있어야 하고, 만약 오해가 생기면 자동으로 새로운 토큰을 가져와 편집을 다시 시도해야 한다.

시간이 걸리는 경우, 구성은 현재 $wgObjectCacheSessionExpiry에 기본값인 1시간을 사용하고 있다.시간 초과에 대한 최근 변경 사항은 보이지 않지만, 페이지 보기가 더 이상 세션 타이머를 재설정하지 않도록 세션 처리에 대한 최근 변경 사항이 있었음을 알 수 있다.Anomie⚔ 13:05, 2015년 3월 3일 (UTC)

만약 내가 너라면, 나는 mediawiki.api.edit 모듈과 친구들을 사용하기 위해 봇을 다시 쓸 것이다. 이 모듈들은 자동 토큰(refetting), 약속 등을 사용하고 api 오류를 감지한다.이것의 사용 예는 여기에서 찾을 수 있다.그리고 요청 실패에 적절한 로깅을 추가하여 어떤 오류가 발생하는지 추측하지 말고 알 수 있도록 하십시오.—DJ (대화 • 기여) 13:54, 2015년 3월 3일 (UTC)

mw.user.tokens를 사용하고 있고 잘못 깨진 고장 여부를 확인하지 않는 것으로 확인됨.그것이 아마도 그것이 실패하는 이유일 것이다.이 토큰들은 유효한 '사전 생성된' 토큰이지만, 당신의 요청은 어떤 이유로든 잘못된 토큰으로 실패하면 당신의 스크립트는 새로운 토큰을 가져올 수 있게 되어 있다. mw.Api는 이러한 제약조건에 대해 알고 있으며 필요에 따라 그 제약조건을 적용하거나 복구한다.—DJ (대화 • 기여) 14:06, 2015년 3월 3일 (UTC)

모두들 응답해줘서 고마워.mw를 사용하도록 코드 수정.api는 모든 것을 작동하게 만든다.실행 당시가 아니라 페이지로드에서 mw.user.tokens가 토큰을 생성하는지 몰랐다.사실 나는 토큰이라는 생각을 다 같이 오해했다.어느 쪽이든, 나는 지금 모든 일을 하고 있어, 그래서 임무를 완수했어!다시 한 번 고마워!--Dudemanfellabra (대화) 09:25, 2015년 3월 4일 (UTC)

@Dudemanfellabra: 당신은 mw의 어떤 사용도 포장하기를 원할 것이다.api withmw.loader.using( 'mediawiki.api.edit' ).done( function() { usage here } )페이지의 다른 어떤 것도 모듈을 아직 로드하지 않은 경우 편집 모듈이 요청 시 로드되도록 보장하기 위해.리소스 로더 모듈을 사용하여 사용자 스크립트 개발—DJ (대화 • 기여) 10:26, 2015년 3월 4일 (UTC)

위키피디아는 서버의 가동 시간과 응답 시간에 대한 통계를 수집하고 있는가?

위키피디아에서 페이지를 구할 수 없는 경우가 있는데, 서버가 다운되거나 일시적으로 과부하된 것으로 보인다.이런 일이 일어날 때, 나는 내 컴퓨터, 네트워크, 위키피디아에 문제가 있는지 모른다.나는 보통 다른 웹사이트를 시도해서 문제를 진단하지만, 위키피디아에 문제가 있는지는 정말 알 수 없다.

내 이메일 공급자는 나에게 pingdom에 대한 링크를 주는데, 여기서 이메일 서버가 다운되었는지 쉽게 알 수 있다.위키피디아는 다운타임, 응답 시간 또는 서버 로드를 추적하고 있는가?어디를 봐야 하지?

위키백과 응답 시간의 그래프를 가지고 있다면, 위키백과가 가볍게 적재되었을 때 사용할 계획을 세울 수 있을 것이다.

고마워요.

Comfr (대화) 04:32, 2015년 3월 3일 (UTC)

http://gdash.wikimedia.org/에서 많은 데이터를 사용할 수 있음 - 일부 "응답-응답" 그래프는 없지만... --Malyacko (talk) 08:32, 2015년 3월 3일(UTC)

지위에 관한 약간의 정보가 있다.wikimedia.org, 예: HTTPS 위키백과의 응답 시간. --Sitic (대화) 22:13, 2015년 3월 3일(UTC)

메달 아이콘에서 연결

여보세요

{{gold1}}{{{{link}}}}}}을(를) {{sort}} 템플릿에 링크하여 옵션 타겟으로 연결되도록 메달 템플릿을 만들려고 했다.잘 작동하지만 {{gold1}에 링크를 제공하지 않을 때는 전혀 연결되지 않는 대신 금메달 아이콘 자체에 연결된다.내가 뭘 잘못한 거지?

예를 들어, 브리트니 보우 기사, "결과 개요" 섹션을 확인해 보십시오. 여기서 마지막 줄의 금메달 아이콘을 기사에 연결하면 효과가 있지만, 같은 줄의 다른 금메달 아이콘은 아이콘 자체에 연결된다.나는 그것을 원하지 않고, 공급된 링크 파라미터가 비어 있는데 왜 이런 일이 발생하는가?

핸섬펠라 (대화) 14:42, 2015년 3월 3일 (UTC)

네가 원했던 결과야?내 편집을 참조하십시오. --Edgars2007(대화/출연) 15:26, 2015년 3월 3일(UTC)

그래, 그렇지.그러나 파라미터는 기본적으로 비어 있는데 왜 메달 아이콘으로 연결되지 않기 위해 코드를 추가해야 하는가?핸섬펠라 (대화) 15:50, 2015년 3월 3일 (UTC)

이제 보니 그 파이프 캐릭터를 놓쳤구나.고마워요.핸섬펠라 (대화) 17:21, 2015년 3월 3일 (UTC)

팝업이 작동하지 않음

...지난주 후반부터 다양한 새 파이어폭스 버전과 상당히 오래된 버전을 실행하는 여러 Mac에서 시작.나는 가젯을 비활성화한 다음(위키링크에서 호킹하면 표적 이름만 있는 노란색 상자가 제공됨) 가젯을 다시 활성화(위키링크에서 맴돌면서 아무것도 나타나지 않는 상태로 되돌림)하고 캐시 제거/새로 고치는 시도를 해 보았다.enwp뿐만 아니라 commons에서도 마찬가지다.파이어폭스가 WP에 오랫동안 접속하지 않은 Mac에서는 팝업이 작동한다.그래서 '어느 정도 수준에서의 어떤 것'이 '다른 것'과 양립할 수 없는 것으로 바뀐 것 같지만, 무엇을, 어디서 더 진단해야 할지 모르겠다.DMACks (대화) 04:08, 2015년 3월 1일 (UTC)

그것은 윈도우 비스타의 파이어폭스와 나에게 효과가 있다.로그아웃해서 https://en.wikipedia.org/w/index.php?title=Example&withJS=MediaWiki:Gadget-popups.js&withCSS=MediaWiki:Gadget-navpop.css을 클릭하면 되는 거야?그것 또한 나에게 효과가 있다.프라임헌터 (대화) 04:25, 2015년 3월 1일 (UTC)

팝업은 OSX 10.9.5, Firefox 35에서 나를 위해 일한다.키건 (토크) 05:42, 2015년 3월 1일 (UTC)

FF 35.0.1 edit: 36.0으로 업데이트되었으며, 팝업도 여전히 정상임.키건 (토크) 05:44, 2015년 3월 1일 (UTC)

제거된 AdBlock(이전에는 문제가 되지 않았지만 배제하는 편이 나을 수도 있음) 또한 나의 common.js에서 수동으로 가져오려고 했지만, 여전히 아무 것도 없었다.DMACks (대화) 10:22, 2015년 3월 1일 (UTC)

(기사 제목을 우연히 맴돌다가) 팝업창이 뜨더니 며칠 전에 가기를 거부하는 이상한 문제가 생겼지만 나에게는 효과가 있다.어떤 OS를 실행하십니까?Whatamidoing (WMF) (토크) 19:58, 2015년 3월 4일 (UTC)

입력

스머프 버튼은 언제 받았지?<inputbox>? 위키백과 참조:Editnotice#편집자 작성 중. -- Gadget850 ^talk 21:43, 2015년 3월 1일(UTC)

안녕. 여기는 "mw-ui-button" CSS 클래스야.그것은 여기 입력 상자에 추가되었다: https://phabricator.wikimedia.org/rEINB7ce80c51a5f0c6ee8e78758afb924bc18b00d525.2015년 3월 1일(UTC) 22:06, --MZMcBride (토크)에서 mw-ui 관련 변경 사항을 추가로 확인할 수 있다.

@MZMcBride: 그러나, CSS의 구체적인 내용은 무엇인가?class="mw-ui-button"내가 질문하는 이유는 그 수업이 위키아이에 아직 존재하지 않기 때문이다.따라서, 나는 지역적으로 수업 세부사항을 추가해야 한다. 불행히도, 나는 그 페이브릭레이터 페이지에서 간단한 CSS 설정을 구별할 수 없었다.고마워! — SpikeToronto 18:57, 2015년 3월 3일 (UTC)

안녕 스파이크토론토.MediaWiki의 최신 버전은 계단식 스타일시트에 Leth를 사용한다.".mw-ui-button" 관련 코드는 다음과 같다: https://github.com/wikimedia/mediawiki/blob/0c8327466bebd44a9c0f60cd010307446b9ead63/resources/src/mediawiki.ui/components/buttons.less> (이 검색을 통해 검색됨). --MZMcBrid (talk) 05:22, 2015년 3월 4일 (UTC)

@MZMcBride:고마워!!— SpikeToronto 20:29, 2015년 3월 4일 (UTC)

테이블 엔드 템플릿

엔딩 테이블의 내용은 매우 다양하며 }.

컨텐츠가 동일한 {{End}}(으)로 리디렉션하고 인스턴스를 다음으로 교체할 것을 제안한다.{{End Foo}}여기서 "Foo"는 이 편집에서와 같이 테이블을 시작하는 템플릿의 이름이다.

결국, 봇은 우리를 대신할 수 있었다.Andy Mabbett (Pigsonthewing); Andy와 대화; Andy가 편집한 2015년 3월 3일(UTC)

• 지원 -- Gadget850 ^talk 20:06, 2015년 3월 3일 (UTC)
• (ec) 리디렉션은 괜찮지만 템플릿을 {end...{}은(는) 그다지 유용하지 않으며, 다른 명백한 템플릿 쌍을 다소 혼동한다. -- [[User:Edokter]] {{talk}}20:08, 2015년 3월 3일 (UTC)
  • 사실 그것은 어떤 경우에는 그것을 더 명확하게 한다.앤디의 예에서 그 쌍은 {{public art table}/{public art footer}}}이다.그리고 많은 템플릿은 단순히 {{end}}을(를) 사용한다. -- Gadget850 ^talk 20:14, 2015년 3월 3일(UTC)
    • 이 경우 최종 템플릿은{{End Pubic art table}}- 테이블의 시작과 쉽게 일치한다.Andy Mabbett (Pigsonthewing); Andy와 대화: Andy가 편집한 22:52, 2015년 3월 3일(UTC)
      • "Pubic art table"은 재미있는 오타다.그래서 제안된 시스템의 바로 그 예는 이미 잘못되어, 출처를 찾아 '공공의 예술'을 찾아 종말을 찾는 능력을 상실하고, 나중에 그것을 원한다면 {{End}}이 파라미터를 검출하는 것을 불가능하게 만든다.프라임헌터 (토크) 13:24, 2015년 3월 4일 (UTC)
• 반대. 템플릿은 {{Public art header}}, {{Public art footer}} 등의 쌍에서 가져온 것이다.현재의 시스템은 예를 들어 하단에 어떤 것이 추가되거나 더 이상 테이블이 아닌 경우, 쌍의 구현을 쉽게 변경할 수 있는 능력을 우리에게 준다.당신의 제안{{End Public art table}}이론적으로 {{End}}의 매개변수 값을 테스트하여 구현을 변경할 수 있으며, 다음에 대해 다른 작업을 수행할 수 있다.Public art table그러나 그것은 사용자들이 항상 파라미터를 기억하고 항상 정확히 같은 값을 줄 것을 요구한다.파라미터는 {{End}까지 무시되므로 사용자가 생략하거나 잘못 입력해도 아무런 차이가 없다.그리고 {{End}}}은(는) 좋은 이유로 완벽하게 보호되지만, 현재 보호되지 않은 {{Public art footer}}와 같은 저사용 사례의 구현을 변경하기 위해 대부분의 편집자들이 도움이 필요하다는 것을 의미한다.또한 Special을 사용할 수 있는 능력도 잃게 될 것이다.WhatLinksHere/템플릿:예를 들어 Special과 비교하기 위한 공공미술 바닥글:WhatLinksHere/템플릿:공공미술 헤더.쌍은 다음과 같다.{{Public art header}}그리고{{Public art footer}}Wikitext에서 특히 선을 시작할 때 더 쉽게 찾을 수 있다.나는 제안된 시스템의 큰 이점이 없다고 본다.wikitxt가 갑자기 수용을 중단하면 더 쉽게 해결할 수 있을 것이다. }테이블 끝의 암호로 사용하지만 그럴 가능성은 거의 없어 보인다.프라임헌터 (대화)20:26, 2015년 3월 3일 (UTC)
  • 「[]더 이상 테이블이 아닌 경우」, 「{{End}}의 파라미터 값 테스트」와 같이 실현 가능성이 없는 가상 시나리오를 고려하고 있는 것으로 보인다.Andy Mabbett (Pigsonthewing); Andy와 대화: Andy가 편집한 22:52, 2015년 3월 3일(UTC)
    • 물론 그것은 가상의 것이다.그는 단지 그것이 전부라고 말하지 않았는가?그 옵션을 계속 열어두려면?과거에 그런 변화가 있었다.디브와 테이블 구조의 전환은 꽤 흔한 일이었고, 아직 마지막을 보지 못한 것 같다.나는 대체하지 말라고 충고한다.리디렉션은 가능하지만, 대신 사람들이 대상을 사용하도록 이끌 수 있다.간접적인 전폐는 적절해 보이지만, 의지는 더 많은 자원이 될 수 없었다.—DJ (대화 • 기여) 00:27, 2015년 3월 4일 (UTC)
    • 그 제안은 문제를 찾는 해결책처럼 보인다.해결할 문제가 없다면 현재의 유연성을 파괴하고 잠재적인 문제를 만들 이유가 없다.{{Col-end}}}이(가) 항상 테이블 끝을 가질지 누가 알겠는가?만약 우리가 {{end}}까지 사용을 대체한다면 아마도 그렇게 될 것이다. 왜냐하면 우리는 그것을 바꾸기가 매우 어렵게 되었기 때문이다.현재 라고 되어 있다.<p></p> }(여기 코드 표시에서 생략된 줄) 그래서 나는 현재 버전이 제안서에서 실제로 제외될 것이라고 추측한다.많은 엔드 템플릿이 분리된 테이블 엔드가 아니거나 미래에 그렇지 않을 수 있다.{{멀티콜엔드}}는</div> }</div>.{{축구 선수단 엔딩}}은(는) } }.{{확장 축구 선수단 엔딩}}}이(가) 있었었다. }2010년 이후 그러나 지난 주에 소스를 제공하거나 요청하는 코드를 추가했다.그리고 문서에 다음과 같은 내용이 있는 {{S-end}}을(를) 고려하십시오(실제로 현재와 같은 방식으로 작동하는지 알 수 없음).이어 "다양한 승계 박스 템플릿은 항해 콘텐츠로 간주돼 PDF나 인쇄 책자에서 인쇄 대상에서 제외된다.단, {{end}}}은 어떤 테이블도 끝내는 데 사용할 수 있으므로, 템플릿은 인쇄에서 제외할 수 없다.다만 {{s-end}}은(는) 부정적인 영향 없이 제외할 수 있다.인쇄에서 제외해야 할 테이블의 끝부분이 명확하지 않은 유사한 템플릿은 {{end}}에 리디렉션되어야 한다." 템플릿을 리디렉션하면 일부 사용자가 대상을 대신 사용할 가상이 아니라 확실하다.프라임헌터 (토크) 01:02, 2015년 3월 4일 (UTC)
      • "{Col-end}}인 경우...현재 라고 말하고 있다<p></p> }"그렇다면 그것은 분명히 이 제안의 범위 밖이다; 따라서 적색 청어(그리고 논리적으로는 짚단 사람)이다.Andy Mabbett (Pigsonthewing); Andy와 대화; Andy가 편집한 09:11, 2015년 3월 4일(UTC)
        • 선택한 서식에 따라 테이블이 여러 가지 방법으로 끝날 수 있다는 것을 보여주는 예다.이번 건은 로부터 시작됐어 } }그러나 나중에 되었다. }그래서 그것은 이 제안서 안에 있어서 오래된 포맷을 복원할 수 없을 것이다.프라임헌터 (토크) 13:24, 2015년 3월 4일 (UTC)
    • 나는 그들이 "hypothemical"이라고 말한 것이 아니라 "불가능한 가상 시나리오"라고 말했다.Andy Mabbett (Pigsonthewing); Andy와 대화; Andy가 편집한 09:11, 2015년 3월 4일(UTC)
• 최종 템플릿을 {{end}}(으)로 리디렉션하는 것에 동의하지만, 프라임(Prime)이라는 이유로 인스턴스를 교체해서는 안 된다.사냥꾼은 철자를 쓴다.누군가 최종 템플릿 중 하나를 변경할 필요가 있다면, 그것은 한 번의 편집 작업과 봇 작업이 필요한 작업의 차이일 것이다.— 미스터 스트라디바리우스 00:52, 2015년 3월 4일 (UTC)
• 프라임당 반대헌터. 이것은 이러한 템플릿의 현재 구현과 너무 엄격하게 연관되어 있으며, 언젠가 우리가 그렇게 하기를 원한다면 개별적으로 다른 구현으로 바꾸기가 훨씬 더 어려울 것이다.그리고 이것이 고칠 현재 시스템의 어떤 점이 고장 났는가? —David Eppstein (토크) 00:03, 2015년 3월 5일 (UTC)

캡챠가 제대로 작동하지 않음

내가 여기서 보고했지만 소용이 없었던 문제가 다시 일어났다.이것은 분명히 깨져서 고쳐야 할 필요가 있는 것 같다.어떤 친절한 사람이 그것을 버그로 기록할 수 있을까? 109.151.63.210 (대화) 21:50, 2015년 3월 4일 (UTC)

mw:를 참조하십시오.버그를 보고하는 방법(정확한 단계, 브라우저 및 OS 정보 등)--AKlapper (WMF) (토크) 08:11, 2015년 3월 5일 (UTC)

기부 로그

내가 편집자의 기고문을 찾아가서 그의 로그를 클릭하면 '모든 공개 로그'가 나온다.내가 관리자로서 기부를 할 때, 나는 아무리 자주 그들의 모든 공공 로그에 관심이 없고, 모든 로그에, 또는 심지어 모든 비공개의 로그에 관심이 있다.하지만, 현재 나는 편집자가 그 중 한 곳에 로그인했는지, 어떤 이유로 로그인했는지 확인하기 위해 모든 비공개 로그들을 일일이 살펴봐야 한다.시스템을 표준 표시 '내 사용자 권한으로 볼 수 있는 모든 로그'(일반 사용자의 경우 '모든 공용 로그'로 기본 설정)와 '모든 공용 로그'(계정 생성, 이동 작업 등 모든 정규 정보에 대한 개요를 얻기 위해 모든 공용 로그) 및 '모든 비공개 로그' 두 가지 옵션으로 변경할 수 있는가?사용자가 문제에 부딪혔거나 사용자가 왜 문제가 있는지) 드롭다운 메뉴에서 두 번째와 세 번째. --Dirk Beetstra 03:38, 2015년 3월 5일(UTC)

액세스 날짜 검사기에 버그가 있을 수 있는가?

Circular prime 기사에서 Reference 섹션은 나를 위해 다음과 같이 표시된다(볼딩은 내 것이다).

1. 세계 수학책 Darling, David J는 1달러 2센트 체크 날짜 값: accessdate= (도움말)
2. Prime Numbers - Wells, D 수학에서 가장 신비한 수치가 1달러 2달러의 날짜 확인 값: access date= (도움말)
3. Circular Primes, Patrick De Geest, 2010년 7월 25일 회수
4. 오즈의 수학: 가장자리 너머의 정신 체조, 피커버, 클리포드 A, 1달러 2달러의 날짜 값 확인: accessdate= (도움말)

지정된 액세스 날짜 대신 $1 $2가 표시되고 있기 때문에 액세스 날짜의 유효성을 검사하는 방식에 문제가 생긴 것 같다.그 암호에 익숙한 사람이 좀 봐줄래?고마워, 28바이트 (대화) 15:08, 2015년 3월 5일 (UTC)

The Universal Book of Mathematics, Darling, David J., retrieved 25 July 2010 (see page 70){{citation}}: 날짜 값 확인: (도움말) 사용 중 accessdate=25 July 2010 (see page 70)데이트가 좋지 않은 거지그러나 이것이 변수를 노출시켜서는 안 된다.모듈 토크에서 보고됨:인용/CS1/아카이브 11#날짜 확인. -- Gadget850 ^talk 15:13, 2015년 3월 5일(UTC)

테크 뉴스: 2015-10

16:42, 2015년 3월 2일 (UTC)

문서화된 도움말의 직접 섹션 링크:섹션#직접 섹션 링크. -- Gadget850 ^talk 15:41, 2015년 3월 6일(UTC)

범주가 엉망이 되었는가?

오늘날까지, 카테고리는 같은 편지에 따라 분류된 기사들을 나누지 않으려고 노력하는 것으로 보인다.어떤 큰 범주의 경우, 이것은 200개의 항목으로 이루어진 하나의 열로 나타나는데, 이것은 우스꽝스럽게 보인다.이것은 사이트 전체의 변화인가, 아니면 내 목적의 문제인가?—Xezbeth (대화) 08:23, 2015년 3월 5일 (UTC)

분할할 헤딩이 없더라도 세 개의 컬럼이 보여. (아마 브라우저 관련인가?)고양이의 첫 번째 기사 이후에 갈라진 부분이 있지만 처음 200개에는 다른 칼럼이 없다면(예를 들어, 나는 https://en.wikipedia.org/w/index.php?title=Category:Living_people&from=9th%20W),에서 각 칼럼 1개와 2개의 칼럼을 볼 수 있는데, 이것은 여전히 꽤 우스꽝스러운 일이다.—크립틱 08:34, 2015년 3월 5일 (UTC)

나는 크롬이 있는 단일 컬럼만 받는데, IE는 그런 문제가 없어.그렇다 하더라도, 우리가 지금까지 가졌던 획일적인 범주에 비해 모든 곳에 다른 크기의 기둥들이 있는 것은 어리석어 보인다.—Xezbeth (대화) 08:47, 2015년 3월 5일 (UTC)

테이블에서 CSS 열로 전환된 범주.그러나 그 실행에는 약간의 사소한 오류가 있기 때문에 나는 다음과 같이 의견을 덧붙였다.T55130.-- [[User:Edokter]] {{talk}}09:26, 2015년 3월 5일 (UTC)

크롬으로 된 두 개의 컬럼이 있는데, 첫 번째 컬럼은 5~6개의 항목만 들어 있고 나머지는 모두 두 번째 컬럼에 채워져 있고, 세 번째 컬럼이 있어야 할 공백이 있다.로저 (Dodger67) (대화) 18:09, 2015년 3월 6일 (UTC)

보이지 않는 템플릿

템플릿 {{oldpuffull}}과(와) {{oldffdfull}}이(가) en에만 표시되어 있다.wikipedia.org, 그러나 en.m에는 아니다.wikipedia.org.이로 인해 모바일 웹사이트 이용자들이 혼란을 겪게 된다.이 문제의 원인은 무엇이며 어떻게 해결할 수 있는가? --Stefan2 (대화) 19:51, 2015년 3월 6일 (UTC)

이런 현상을 일으키는 것은 바로 그 존재감이다.tmboxclass. 모바일 사이트에 CSS 선언이 있음display: none !important;tmbox를 포함한 여러 클래스에 적용됨.그것은 정확히 그 문제와 같은 문제야.navbox그리고metadata이 페이지에 가끔 올라오는 수업. --Redrose64 (토크) 20:04, 2015년 3월 6일 (UTC)

그래, 나는 이 주제에 대해 모바일 팀을 좀 비난하고 있어.지금까지 이 모든 숨김이 그리 나쁘지 않았지만(어쨌든 어떤 위키피디아 사람들이 모바일 사이트를 이용하고 있었다), 그들은 어떻게 그러한 숨겨진 콘텐츠 블록을 줄이고 더 나은 방법으로 같은 정보를 제시할 수 있는지에 대해 시간을 투자하기 시작할 필요가 있다.예를 들어, 내 폰에서는 네비박스가 전혀 무의미하지만, 네비박스의 내용을 사용할 수 있는 방법이 있어, 모바일에 비슷한 요구를 충족시킬 수 있어.(예를 들어 관련 물품의 카루즈).마찬가지로, 나는 작은 전화기에서 전체 섹션 앰박스를 보고 싶지 않을 수도 있지만, 오른쪽 떠 있는 작은 경고 버튼이나 정보를 보여줄 수 있는 어떤 것을 보고 싶을 수도 있다.모르겠어, 그냥 아이디어만 던져놓고.—DJ (대화 • 기여) 21:22, 2015년 3월 6일 (UTC)

파일 이동 필요

파일 다시 만들기:제럴드 패리나스는 하와이에 있는 시로의 사이민 헤이븐에서 사이먼을 만났다.JPG, 나는 이것을 Move to Commons Assistant와 함께 Commons로 복사해 보았다.전체 파일 이미지 이름은 다음과 같이 나오지 않는다.1단계.나는 조교와 함께 다른 이미지들을 커먼스에 복사했고 아무런 문제가 없었다.나는 이 파일 이름이 너무 길어서 조수가 알아볼 수 없다고 생각한다.단축된 이름으로 프로세스를 계속하면 해당 파일이 존재하지 않는다는 메시지가 나타난다.내 말이 맞다면 파일 무버 권한을 가진 사람이 좀 더 적절한 이름으로 옮기시겠습니까?— 마일 (대화) 2015년 3월 6일 20:42, (UTC)

PDF 생성기

위키의 PDF 생성기는 여전히 펑키하다.지난 며칠 동안 기사의 pdf 파일을 생성하고 다운로드하려고 할 때마다 '위키' 재단 오류가 발생한다.누군가가 그것을 들여다볼 것인가 아니면 그것에 대해 뭔가를 할 줄 아는 누군가에게 이 메시지를 전달할 것인가?Thnx. -- Gwilhickers (대화) 23:00, 2015년 3월 4일 (UTC)

@G윌리커즈:이런 일이 오직 큰 책에서만 일어나는가, 아니면 단문 PDF로도 일어나는가?HHVM 및 조사로 인한 대형 서적 문제에 대해 잘 알고 있으며, 자세한 내용은 다음 자료를 참조하십시오.T89918.--에릭 몰러 (WMF) (토크) 05:39, 2015년 3월 5일 (UTC)

@에릭 몰러(WMF): 한 가지 기사를 다운받으려고 해도 위키 재단의 오류가 나고 있었다.그러나 지금 막 나는 아브라함 링컨에 관한 PDF를 다운받을 수 있었지만 율리시스 S. 그랜트 기사로 그렇게 하려고 했을 때 위키의 오류를 얻었다.단지 문제를 복잡하게 하기 위해서입니다. -- Gwilhickers (대화) 21:46, 2015년 3월 5일 (UTC)

@Gwillhickers: 그래, 업데이트해줘서 고마워.이것은 아마도 같은 문제일 것이다. 매우 큰 파일로 인한 시간 초과.최대한 빨리 이 문제를 해결하는 것을 목표로 할 겁니다. 불편을 끼쳐드려 죄송합니다만.--에릭 몰러(WMF) (토크) 06:30, 2015년 3월 7일 (UTC)

논발행

여기 나와는 상관없는 일이지"아니, 우리는 철자 검사기나 철자 검사 봇을 추가하지 않을 겁니다.위 웹 브라우저인 파이어폭스 같은 철자체크기를 사용할 수 있다." 위는 관심없지만 왜? –DangerousJXD (토크) 10:39, 2015년 3월 7일 (UTC)

WP:FDB#완전 자동 철자 검사 봇 참조. --Redrose64 (토크) 11:16, 2015년 3월 7일 (UTC)

@DangerousJXD:AutoWikiBrowser, WPCleaner 및 WikiDi와 같은 도구를 사용하여 철자 오류를 찾아 수정할 수도 있다.위키백과 참조:AutoWikiBrowser/Typos(오타 규칙 목록 및 기타 정보)GoingBatty (토크) 13:33, 2015년 3월 7일 (UTC)

리디렉션된 대화 페이지에서 작업하지 않는 반짝임

사용자 대화 시:RightBKC 나는 카피비오 경고를 남기려고 하지만 "사용자 대화 페이지 수정:다음에 대한 리디렉션을 확인할 수 없음: User_talk:RightBKC".그 페이지에 대한 기록도 찾을 수 없지만, 어떤 기록도 찾을 수 없어.고마워요.더그웰러 (대화) 2015년 3월 7일 12:21, 7 (UTC)

그거 참 이상하네.트윙클이 해결할 수 없는 이유(페이지가 저절로 리디렉션됨)는 이해하지만, 왜 로그에 페이지가 삭제된 것으로 표시되지만 편집된 내용이 없는지는 이해할 수 없다(생성되지 않은 것은 삭제할 수 없는 것 맞지?)네가 과묵한 사람이니깐, 내 생각엔 과묵한 편집은 없을 것 같은데, 맞지?만약 있다면, 그것은 잃어버린 역사를 설명할 수 있을 것이다; 만약 그렇지 않다면, 글로벌 이름 바꾸기 기능에 뭔가 잘못된 일이 있을 수 있다.28바이트(대화) 12:47, 2015년 3월 7일(UTC)

고마워. 아무것도 안 보여서 역사가 없을지도 몰라.적어도 두 명의 편집자가 이 사용자에 의해 카피비오를 되돌렸지만 그에게 경고한 것으로 보이지는 않는다.더그웰러(대화) 13:25, 2015년 3월 7일 (UTC)

데이터베이스 오류, 나는 [20]을 가리켰다.더그웰러(대화) — 선행 미등록 의견 추가 14:58, 2015년 3월 7일(UTC)

페이지 정보 페이지의 오래된 링크

"페이지 정보" 페이지(예: [21])는 로컬 관리자가 편집할 수 있는가(아마도 Mediawiki: 페이지를 통해)?바닥글의 툴서버에 대한 구식 링크가 있다는 것을 알게 되었다.28바이트(대화) 13:02, 2015년 3월 7일(UTC)

이 목록 말하는 거야? --Redrose64 (대화) 13:15, 2015년 3월 7일 (UTC)

그래, 내가 찾던 게 바로 그거야.고마워! 28바이트 (대화) 13:47, 2015년 3월 7일 (UTC)

웃기는 건 내가 전에 그 페이지를 편집해 본 적이 있어서야늙어가는 게 틀림없어...28바이트(대화) 13:48, 2015년 3월 7일(UTC)

?uselang=qx 또는 &uselang=qx는 사용된 MediaWiki 메시지의 이름을 표시함: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&action=info&uselang=qqx. 프라임헌터 (토크) 2015년 3월 7일 14시 12분 (UTC)

매우 편리하다, 고마워! 28바이트 (대화) 23:53, 2015년 3월 8일 (UTC)

표에 있는 헤더 셀의 배경색.

조금 전부터 (언제까지 정확히) 테이블 헤더 셀(=로 코딩된 셀)을 표로 한다.!대신에 )은 사이트의 모바일 버전에 더 이상 배경색이 없다.왜 그런 것일까요?게다가, 심지어 데스크탑 버전에서도 그들의 배경색은 훨씬 더 가벼워졌고, 특히 전체 테이블에 대해 배경색이 코드화된 경우 거의 눈에 띄지 않는다.전혀 대조가 없다. 왜일까?다른 많은 위키피디아들은 헤더 세포의 배경색이 훨씬 더 어둡다(그리고 내 생각에 더 좋다고 생각한다)만약 그것이 중요하다면 나는 일반적으로 데스크탑 Safari 8.0.3을 사용한다.TVx1 02:15, 2015년 3월 8일 (UTC)

의 데스크톱 CSSwikitable클래스는 에 정의되어 있다.mediawiki.legacy/shared.css 최근 패딩의 변화가 있었지만, 색상은 없었다.예를 들어 주시겠습니까?

모바일 CSS 리포지토리가 어디에 있는지 모르겠다.(이름?)하지만 테이블 배경이 투명하게 설정되어 있는 것을 알 수 있다.그 이유에 대해서, 나의 SWAG는 누군가가 그것이 좋은 생각이라고 생각했기 때문이다. -- Gadget850 ^talk 12:37, 2015년 3월 8일 (UTC)

모바일 프런트엔드 확장.모든 스타일링 파일. -- [[User:Edokter]] {{talk}}14:12, 2015년 3월 8일 (UTC)

이곳에서는 테이블 색상의 변화는 없었지만, 네덜란드어 위키피디아가 헤더 셀에 대해 더 어두운 색상을 설정했다는 점에 주목한다. -- [[User:Edokter]] {{talk}}14:12, 2015년 3월 8일 (UTC)

알았어. 만약 바탕화면에서 색이 바뀌지 않았다면 내가 틀렸을지도 몰라.나는 대비가 줄었다고 생각했는데 내가 착각한 것 같아.그래도 머리 색깔은 좀 밝은 것 같아.Tvx1 22:43, 2015년 3월 8일(UTC)

참조 목록 및 Wikisource 템플릿

Firefox 36.0.1을 사용한 Writer 기사를 보면 수많은 {{Wikisource} 템플릿 위에 참조가 표시된다.Internet Explorer 11을 사용하여 같은 기사를 보면 참고문헌은 {{Wikisource} 템플릿 이후에 시작한다.이 기사가 어떻게 표시되는 것이 올바른가?고마워!GoingBatty (토크) 15:57, 2015년 3월 8일 (UTC)

파일 이동:Tomas Transstromer와 Modhir Ahmed.jpg가 이 문제를 해결할 것이다.관련 없는 Wikisource 템플릿도 제거될 것이다.-- Gadget850 ^talk 17:09, 2015년 3월 8일 (UTC)

@Gadget850:노벨상을 수상한 시인의 그림은 시상 부문으로 되어 있는 것으로 보인다.이미지와 Wikisource 템플릿이 (그 템플릿이 없을 수도 있을 만큼) 충분히 중요하다고 가정할 때, 다음 단계는 무엇인가?GoingBatty (토크) 21:34, 2015년 3월 8일 (UTC)

이미지가 섹션보다 높아서 문제가 생긴다.{{-}}(공백을 많이 가미할 것)로 클리어하고, 높이나 영화 촬영. -- 가젯850 ^talk 22:08, 2015년 3월 8일 (UTC)

박스형 {{Wikisource} 템플릿은 박스형 {{Wikisource-inline}이(가) 페이지 아래쪽에 있는 내용에 방해가 되는 경우 - Evad37[talk] 23:26, 2015년 3월 8일(UTC)

템플릿이 잘못된 섹션에 있는 경우 시작 - 위키백과:Style/Layout#Links to sister projects에 대한 설명서에는 마지막 섹션에 넣으라고 되어 있는데, Writer에게는 "외부 링크"라고 되어 있지만, 그것들은 "참조"에 있다.그{{commons}}그리고{{commons category}}템플릿은 "이 템플릿을 열이 포함된 섹션에 배치하지 마십시오."라고 조언하지만,{{Wikisource}}하지 않다아마도 그래야 할 것이다. --Redros64 (대화) 00:27, 2015년 3월 9일 (UTC)

@Evad37 및 Redros64:당신의 조언을 종합하여 외부 링크 섹션에 있는 {{Wikisource-inline} 템플릿으로 교체하였다.다른 사람들은 이 템플릿들이 정말 가치 있는 것인지 아닌지를 결정할 수 있다.여러분 감사합니다, 여러분!GoingBatty (토크) 01:35, 2015년 3월 9일 (UTC)

인라인 버전이 있는 줄 알았는데 {{Wikisource}}에서 연동되지 않았다. -- Gadget850 ^talk 01:39, 2015년 3월 9일 (UTC)

개인 대명사 선호 데이터 베이스에 대한 지식

성평등을 달성하기 위한 진행 추세를 확인하기 위해 사용자 페이지에 자체 식별된 '성 대명사 사용 선호도'의 통계적 척도를 동적으로 업데이트하여 양성평등을 향한 진행 추적을 추적하는 데 관심이 있다.이는 기술 사용자 데이터에 대한 관리자 전용 액세스일 가능성이 높다.이 통계를 수집하고 인쇄하는 것이 얼마나 쉬운지 아는 사람?LawrencePrincipe (대화) 21:16, 2015년 2월 13일 (UTC)

@LawrencePrincipe:사실 다음과 같은 "젠더" 마법의 단어를 사용하여 접속할 수 있다.{{gender:username he she unset}}

그러니 들어가면{{gender:Philosopher he she unset}}, 당신은 얻는다.he 모자를 보니 내 취향은 "그"로 되어 있더라.나는 너에게 같은 일을 하고 너의 것이 "설정되지 않은" 것을 본다.– 철학자^{Let us reason together.} 00:14, 2015년 2월 14일 (UTC)

@Philosopher: 비록 통계는 주 단위나 월 단위로 광범위하게 시스템적으로 필요하지만, 효과가 있는 일대일 단위로.즉, 월별 신규 사용자 수 중 여성으로 자명한 비율과 남성 시스템 전체로 자명한 비율이다.시스템 전체에 걸쳐 동적으로 업데이트될 수 있는가?LawrencePrincipe (대화) 00:35, 2015년 2월 14일 (UTC)

위키백과에 나열됨:데이터베이스 보고서/사용자 환경설정이 최신 버전이 아님. -- Gadget850 ^talk 00:53, 2015년 2월 14일(UTC)

@Gadget850:통계는 꽤 괜찮지만, 꽤 오래된 것이다: "사용자 선호도 통계; 2014년 6월 19일 현재 데이터". 이를 갱신하거나 월별 그래프를 얻을 수 있는 방법이 있는가?로렌스프린시페 (대화) 02:01, 2015년 2월 14일 (UTC)

예전 툴서버에서 실행한 것 같아대체자는 모른다. -- Gadget850 ^talk 02:23, 2015년 2월 14일 (UTC)

이 데이터는 유용하거나 의미가 없을 가능성이 매우 낮다는 점에 유의하십시오.이 선호도는 인구통계학적 추적을 위한 것이 아니라 정확하게 그엔더링 언어에 사용되도록 설계되었다. 대부분의 사용자들은 그것을 설정하지 않을 것이다.Andrew Gray (대화) 15:28, 2015년 2월 14일 (UTC)

@Andrew Gray:2010년 유엔 연구에서 나온 성별 통계는 현재 사용되고 있는 유일한 통계 자료로, 날짜가 적혀 있다.최적의 것은 아니지만, "사용자의 성별 선호 선택"을 보면 유용한 근사치를 얻을 수 있다.그것은 최적의 것은 아니지만, 성별 통계의 현재 상태에 대한 약간의 통찰력을 얻는 데 유용하다.새로운 Toolserver 애플리케이션 및 데이터 베이스 액세스에 대해 잘 아십니까?로렌스프린시페 (토크) 2015년 2월 14일 16:02, (UTC)

FWIW, 이것은 유용한 데이터가 될 가능성이 있는지에 대한 WMF Analytics의 지난해 토론이다.Andrew Gray (대화) 2015년 2월 14일 19:51, 14 (UTC)

안녕 Andrew Gray; WMF Analytics의 Ryan Kaldari, Aaron 및 Steven Walling의 대화는 성별 선호 데이터가 이전의 2010 UN 데이터에서 성별 통계를 업데이트하는 차선적인 방법으로 사용된다는 것에 흥미로웠다.만약 그들의 사용자 ID 이름을 가지고 있는 사람이 있다면, 나는 그들에게 ping을 해서 새로운 툴서버를 아는 사람을 찾을 수 있을 것이다.Gadget850이 방금 위에 제공한 링크는 여성 편집자들이 19%로 추정하는 목표물에 강하게 달려있었는데, 이것은 실제로 2010년 UN 번호에 상당히 가깝다.만약 누군가가 새로운 툴서버를 충분히 잘 알고 있거나, 위의 어떤 것(라이언, 애런, 스티브 월링)에 대한 사용자 ID를 가지고 있다면, 나는 그들에게 ping을 할 수 있을 것이다.LawrencePrincipe (대화) 20:46, 2015년 2월 14일 (UTC)

"새로운 툴서버를 알고 있다"는 말이 무슨 뜻인지 잘 모르겠지만, 예전 SQL 질의가 무엇인지 알고 있다면 채석장에서 사용해 볼 수 있다. 툴서버/랩 계정이 필요 없다.그러나 19%는 의미 있는 데이터만큼 무작위적인 확률일 것이라는 점을 강력히 강조하고 싶다.Andrew Gray (대화) 20:56, 2015년 2월 14일 (UTC)

이 링크를 업데이트하는 방법을 알고 있는 사람:위키백과:데이터베이스 보고서/사용자 환경설정LawrencePrincipe (대화) 21:22, 2015년 2월 16일 (UTC)

@LawrencePrincipe:이 보고서를 생성하는 코드는 위키백과에 있다.데이터베이스 보고서/사용자 환경설정/구성툴서버 시대의 것으로 보여서 조정이 필요하겠지만, 적어도 Quarry에서 수정 없이 SQL 쿼리를 실행할 수 있어야 한다(위에서 언급).MZMcBride(그 작가)를 통해 MZMcBride가 작동하도록 할 수 있을 것이다.Matma Rextalk 12:46, 2015년 2월 17일 (UTC)

@Matma Rex: MZMcB는 이전 툴서버를 위해, 지금 통계를 유지하기 위해 필요한 것은 통계를 갱신하기 위해 새로운 툴서버로 업데이트/변환할 수 있는지 여부라고 썼다.이 일을 할 수 있는 방법은?LawrencePrincipe (대화) 01:53, 2015년 2월 18일 (UTC)

(주문하지 않음) 페이브릭레이터:T60196이 여기서 우리를 가로막고 있는 것이다. --MZMcBride (토크) 20:03, 2015년 2월 19일 (UTC)

@MZMcBride:@Rich Farmbrough:그 문제는 월간 단위로 성별 통계를 얻을 수 있는 방법을 찾을 수 있는 것으로 보이는 @Rich에 의해 해결된 것으로 보인다(아래 섹션 참조).당신이 방금 제공한 페이브릭커 링크에 대한 코멘트의 마지막 업데이트는 그 이후로 업데이트되지 않은 14Dec이었습니다.최근 서너 달 간격으로 월별 성별 선호도 통계를 얻을 수 있는 기회가 있는가?LawrencePrincipe (대화) 00:09, 2015년 2월 20일 (UTC)

Wikimedia 연구 통계에 대한 섹션

WMF가 실시한 사용자 설문조사가 있었는데, 그 결과는 아직 발표되지 않았다.사용자의 성별을 이름별로 식별하는 것을 보충 과정으로 기술하는 논문이 있다(어느 논문은 잊어버린다).위키피디아의 젠더 언어 차이에 관한 연구도 있는데, 그 결과 내가 얻은 결론은 증거를 뒷받침하지 않고 일반적인 인터넷 담론에서 위키피디아 담론에 이르는 성별의 말을 추론하는 것은 타당하지 않다는 것이었다.나는 또한 결과가 좋지 않은 표준 "성별 시험기"에 있는 텍스트의 작은 샘플들을 분석했다.그러나 모든 토크 페이지 기여도에 대한 전체 텍스트 분석이 수행되지 못할 이유는 없으며, 성별 식별 사용자로 구성된 유효한 교육이 있기 때문에 성별 예측력이 우수한 모델로 이어질 수 있다.최상의 선택:Rich Farmbrough, 11:46, 2015년 2월 18일 (UTC)

@Rich Farmbrough:네가 언급한 그 논문은 단서가 있으면 찾아내는 데 흥미로울 것이다.새 툴서버를 이용해 여성으로 자칭하는 신규 계정의 수를 세는 문제는 기존 툴서버 앱이 이를 쉽게 처리했음에도 불구하고 수용하기 어려워 보인다.위에서 설명한 연구 앱은 여성으로 자명한 새로운 계정의 간단한 계산이 새로운 툴서버를 알아낼 수 있다면 첫 단계를 제공하겠지만 상당히 진보된 것으로 들린다.로렌스프린시페 (대화) 2015년 2월 18일 (UTC)

마지막 5000개의 신규 계정(편집된 계정)은 남성 9명, 여성 1명, 미설정 4990명이었다.최상의 선택:Rich Farmbrough, 16:13, 2015년 2월 18일 (UTC)

고마워, 리치, 명심해야 할 중요한 사항이다(또한, 사용자 성별을 명시하는 것은 2011년 10월 이후로만 가능하다).

• 채석 마스크 vs 페미니스트 ptwiki_p
• 채석 마스코트 VS 드와키의 페미니스트
• 스웨덴 채석장WP 성별
• 스웨덴 채석장WP 관리자 성별

"그러나 모든 토크 페이지 기여도에 대한 전체 텍스트 분석이 수행되지 못할 이유는 없으며, 성별을 식별한 사용자로 구성된 유효한 교육이 있기 때문에 성별 예측 능력이 우수한 모델로 이어질 수 있다." - 소름끼치게 소름끼칠 것이라는 점만 빼면! --Atlasawa (대화) 2015년 2월 18일 (UTC)

• Quarry Mal 및 여성 사용자들은 enwiki에 대해 설명한다.

신고자: 남성 = 502573, 여성=98369, 여성 = 성별이 공표된 사람의 16.40%.

• 엔위키에서 남녀 행정관

관리자: 여성=56, 남성=600.

최상의 선택:Rich Farmbrough, 17:04, 2015년 2월 18일 (UTC)

@Rich Farmbrough:@Atlasawa:저것들은 놀랄만한 성별 통계들이지만, 50만 명의 남성 편집자들이 언급하는 것은 무엇인가?《이코노미스트지 뉴스위크》는 여기 []^[1]에서 2007년에 총 5만 명의 편집자가 있으며, 2014년에는 3만 명의 편집자로 감소했다고 발표했다.당신의 502,573 번호는 무엇을 의미하며, @Atlasawa가 인용한 2011년 날짜와 관련이 있는가?아마도 간단한 설명이 있을 것이다.로렌스프린시페 (대화) 2015년 2월 18일 (UTC)

20,555,036개의 위키백과 계정 중 대다수는 편집한 적이 없다(또는 편집한 내용이 없다).이러한 회계처리에 대한 몇 가지 분명한 이유가 있으며, 일부는 명확하지 않다.

1. 누군가 공공 기물 파손 행위를 보고 계정을 만들지만, 그것은 그들이 그곳에 도착할 때쯤이면 고쳐진다.
2. 누군가는 계정을 만들지만 편집이 너무 힘들고, 생각이 바뀌고, 산만해지고(오, 나비처럼 보여!)
3. 이름을 보호하기 위해 만든 계정(예: 사용자:자리 표시자 및 WP:DOPPELGANGER 계정) 또는 이름 예약
4. 편집 필터가 허락하지 않아 반란을 일으키고 포기하려는 계정
5. 되었다.
6. 암호를 잊어버렸거나 잘못 설정한 계정
7. 슬리퍼 양말

그리고 아마 몇 개 더 있을 것이다.

그리고 다른 수치는 다양한 정의를 가진 "활성 편집자"에 바탕을 두고 있으며, 보통 월별 또는 연도별 X 편집의 관점에서 그러하다.

최상의 선택:Rich Farmbrough, 18:49, 2015년 2월 18일 (UTC)

LawrencePrincipe, 이코노미스트는 실제로 "전체 편집자"가 아니라 "활성 편집자" (Active Editors = Registered (그리고 로그인한) 사용자), 영어 WP 요약 통계, 2007: 5만 명의 편집자 및 2014: 3만 명의 편집자를 참조한다.다른 대형 WP, 독일 WP 요약 통계 2007: 활성 편집자 9,000명 및 2014: 활성 편집자 6,000명총 (언제나) enWP 등록 사용자: 24,107,661명, 50만 명의 남성 편집자를 매우 작은 부분으로 만든다.관리자도 동일:enWP 관리자 1363명 중 여성 56명, 남성 600명. --atlasawa (대화) 19:28, 2015년 2월 18일 (UTC)

@Rich Farmbrough:그 논평은 모두 동의한 것으로 보인다.이 통계는 마지막 10,000명의 편집자와 마지막 15,000명의 편집자의 결과를 보면 흥미로울 것이다.모두 성 대명사 사용량의 10% 정도로 일관성이 있는가?@Atlasawa:이코노미스트 기사는 또한 영어 이외의 위키피디아는 약 4만2천명의 편집자로 안정되어 있으며, 계절적 변동을 위해 2000년을 오르내리고 있다.리치가 위에서 언급한 모든 이유로 '활성' 편집기 번호는 중요한 번호로 보인다.당신이 제공한 통계와 도구는 위키미디어에서 출판되는 신뢰할 수 있는 데이터로 사용될 수 있는가?로렌스프린시페 (대화) 2015년 2월 18일 21:41, (UTC)

채석장 도구는 거기 있는데, 내가 좀 더 나은 것을 만들 수 있을지도 몰라. (글쎄, 나는 할 수 있지만, SQL을 다시 손질해야 해.)

5k 피규어는 잠재적으로 10k와 15k 피규어를 얻을 수 있다.이 수치를 복제하기 위해서는, 계정들이 자격을 갖추기 위해 편집해야 하는 시간을 명시하는 것이 중요하다.아마 15k 계좌만 나열하는 게 더 간단할 거야

하지만 나는 스티브 월링의 말에 동의한다. 선언된 숫자가 형편없는 대용품이라는 것에.예를 들어 게이머게이트는 여성들에게 자아 정체성을 기꺼이 알리도록 만들었을 수도 있다(또는 그렇지 않을 수도 있다).그러나 잠재적인 교란 요인이다.)

최상의 선택:Rich Farmbrough, 23:36, 2015년 2월 18일 (UTC)

@Rich Farmbrough:2010년 유엔 연구 이후 현재 성별 통계에 대한 새로운 데이터가 없기 때문에 이 모든 통계는 유용할 것이다.만약 당신이 5k, 10k, 15k에 대해 "시간을 명시하는 것이 중요하다"고 말한다면, 만약 그것이 타당해 보인다면, 얼마나 많은 여성들이 등록했는지 나타내는 시간 간격의 두 배가 (약 10k 레벨), 그리고 3배인 시간 간격은 약 15k 레벨로 나타내는 것만큼 쉽게 될 수 있다.각 시간 간격의 실제 숫자는 이야기를 말해준다.여성 "게머게이트"에 대한 당신의 다른 질문에 대해, 만약 여성들이 자기 정체성을 갖는 성별이 성 평등을 더 잘 달성하는 데 도움이 될 것이라는 확신이 주어진다면, 그렇게 할 수 있는 모든 동기를 부여받을 수 있을 것이다.역사적으로 목표를 달성할 수 있는 기회는 종종 참여에 대한 높은 동기부여가 된다.LawrencePrincipe (대화) 00:31, 2015년 2월 19일 (UTC)

물론 여성사, 여성문학 등에 대한 커버리지 개선(성평등을 달성)을 바탕으로 한 에디터톤이 (양성 모두의) 참가자를 유치하는 데 매우 성공적이라 생각한다.그러나 편집하려는 동기는 일반적으로 성 평준화와 관련이 없으며, 이에 대해 정말로 열정적인 사람들은 자신의 시간이 다른 여성과 소녀들에게 편집을 권장하는 데 가장 적합하다고 생각하는 경향이 있다.

5천명의 편집자가 있는 한 2, 3일 정도의 가치가 있다.하지만 샘플은 월 간격으로 가져갈 수도 있고, 그런 것도 있다.최상의 선택:Rich Farmbrough, 00:52, 2015년 2월 19일(UTC)

만약 월별 통계가 편리한 시간 간격이라면, 가능하면 몇 달 간격으로 보는 것이 유용할 것이다.나는 왜 이 데이터가 다른 편집자들에 의해 신뢰할 수 없는 것으로 불리고 있는지 명확하지 않다.이것은 아무도 이러한 데이터가 신뢰성이 없다고 생각하지 않으면서, 새로운 편집자의 수와 주당, 월별 편집 횟수를 세는 것과 동일한 데이터 출처인가?왜 사용자 페이지에서 개인 대명사 선호도 선택을 세는데 신뢰성이 없다고 하는가?로렌스프린시페 (대화) 20:37, 2015년 2월 28일 (UTC)

완전하지 않아서 믿을 수 없다.당신의 성별을 공개하는 것은 선택사항이다: 실생활에서 만난 사람들은 내 성별을 알고 있지만, 나는 그것을 전자적으로만 아는 사람들로부터 숨길 수 있다.{{he or she Redrose64}}→ 그 또는 그녀.나는 단지 그들이 그렇게 하는 것이 가능하다는 것을 모르기 때문에 성별을 정하지 않은 많은 편집자들이 있을 것이라고 기대한다 - 그리고 어떤 편집자들은 그것이 강제적이지 않다는 것을 깨닫지 못한 채 그것을 정했을지도 모른다.이와는 대조적으로 내가 편집한 횟수는 영구히 기록되고, 더구나 숨길 수 없는 것이다. --Redros64 (토크) 20:23, 2015년 3월 1일 (UTC)

위키백과_토크에서 작은 그래프를 만들어 보았다.위키프로젝트_Countering_systemic_bias/Gender_gap_task_force#F.2FM_ratio_of_gender_identify_editors_on_en:월별 편집자를 식별하는 새로운 성별의 성비를 보여주는 WP.최상의 선택:Rich Farmbrough, 01:16, 2015년 3월 4일 (UTC)

Redrose와 Richf; 그 그래프들은 그 곳에서의 대화에 대한 코멘트와 함께 매우 좋다.시스템 전반에 걸친 변화로서 성별 선호 사인을 탭으로 만드는 것이 얼마나 어려울지 레드 로즈를 묻는 것이 우선이다.만약 Jhales가 더 많은 양성평등을 위해 심각하다면, 이러한 통계는 진보를 추적하는데 필수적이다.통계 기준이 클수록 데이터의 신뢰성이 높아진다.로렌스프린시페 (토크) 2015년 3월 4일 20:16, 2015년 3월 4일 (UTC)

@LawrencePrincipe:나는 왜 나에게 물어보는 것이 우선순위가 되어야 하는지 모르겠다 - 나는 MediaWiki 개발자가 아니다.시도: (하지만 숨을 죽이지 마, 내 최근 경험으로 판단하건대, 그들 중 한 명이 잘못된 부서로 넘겼기 때문에 아마 "잘못된" 것으로 닫을 거야.) --Redros64 (대화) 20:56, 2015년 3월 4일 (UTC)

페이지 상단에 gendered create account 탭을 주는 것은 환영하는 것처럼 들렸다.로렌스프린시페 (대화) 2015년 3월 5일 20:17 (UTC)

로렌스는 그가 좋아하는 어떤 우선 순위라도 가질 수 있을 것 같아!그리고 정말로 그에게 필요한 한 가지 대답을 해주셨으니, 바로 파브리케이터입니다.

참고로 내가 사용한 수치는 https://meta.wikimedia.org/wiki/User:Rich_Farmbrough/Gender_balance에 있다.

특히 "말하지 않는 편이 좋다"거나 "숨기는" 선택사항, 또는 둘 다 제공된다면 계정 생성에 그것을 추가하는 것이 그리 부담스럽지 않을 것이라는 것을 젠더 프레프스와 ISTM에 대해 생각해 보았다.

최상의 선택:Rich Farmbrough, 23:22, 2015년 3월 7일 (UTC)

그래, 전적으로 동의해."로그인" 탭 바로 옆에는 현재의 "계정 만들기" 탭을 그대로 두고 그 옆에 색상 코드로 된 탭을 놓아 옵션인 "여성용 계정 만들기"(핑크 주홍색 탭)를 사용할 수 있다.Phabricator(@Redros64: 위의 코멘트 참조)는 RfC를 설정해 본 적은 없지만 어딘가에서 RfC를 먼저 원하고 있는 것으로 보인다.만약 누군가가 그것을 할 수 있다면, 위에서 설명한 @Rich Farmbrough의 도구는 양성평등 경향과 위키백과의 추세를 보여줄 수 있는 훨씬 더 풍부한 자료를 제공할 것이다.이러한 "여성 계정 만들기" 탭은 또한 여성 편집자를 위한 현재 편집에 대한 간단한 뉴스 플래시를 다른 사용자들 중 한 가지 용도로 제공할 수 있을 것이다.건배.로렌스프린시페 (대화) 2015년 3월 8일 19:54, 8 (UTC)

특별한 "Create account for women" 핑크 탭은 이 핑크 미니버스만큼 유용하다.아니. 그냥 싫어. --Redros64 (대화) 23:30, 2015년 3월 8일 (UTC)

사용자 대명사 선호도 통계에 대한 데이터 수집

위키피디아에서는 성 격차 문제에 대해 회의적인 시각이 많으며, 현재 약 28%에 달하는 IT 산업 전반의 성 배분은 쉬쉬할 수 없다는 주장도 있다.위키백과에서는 성평등이 가능하거나 성평등이 불가능하다는 이 문제에 대해 선호하는 입장이 있는가(위 Redrose 참조).위의 리치의 도구는 성별 데이터의 추가 공급을 얻는 것에 달려있다. 위키피디아가 이러한 통계들을 심각한 방법으로 추적하기를 원한다면, 당신은 무엇을 제안할 것인가?LawrencePrincipe (대화) 2015년 3월 9일 01:13, 01:13 (UTC)

계정 등록 페이지에서 성별을 지정하기 위해 추가 상자로 사용하는 "로그인 탭" 아이디어:GetingStarted 팀(현재 해체된 팀)은 그런 일을 좀 했다.그들의 전반적인 결과는 가입 과정에 추가되는 모든 질문은 가입하는 사람들이 눈에 띄게 적다는 것을 의미한다는 것이다."사용자 이름, 암호, (선택사항) 전자 메일 주소 및 (선택사항) 성별"을 선택하면 현재 "사용자 이름, 암호 및 (선택사항) 전자 메일 주소 선택"보다 계정이 더 적게 생성된다.WhatamIdoing (talk) 18:17, 2015년 3월 9일 (UTC)

안녕 @WhatamIdoing:그것은 가입서를 그대로 두는 것이 매우 타당해 보인다.가장 큰 문제는 등록 시트에 도착하기 직전 시스템 와이드 스크린의 계정 등록 탭이다.이 새로운 성별 탭은 장기적인 것이 될 필요도 없으며, 위에서 논의한 리치의 새로운 성별 통계 도구에 필요한 데이터를 수집하기에 90일이면 충분할 것이다.시스템 와이드 스크린의 탭은 색상으로 구분되고 일반 "계정 만들기" 탭 바로 옆에 있으므로, "여성을 위한 계정 만들기"로 선택된 후 성별 질문을 다시 물을 필요가 없을 것이다.이는 가입 양식에 대한 질문을 하나 덜 하게 하고, 데이터는 여전히 이러한 통계의 데이터 수집의 시험 기간 동안 수집될 수 있다.건배.로렌스프린시페 (대화) 2015년 3월 9일 19:00 (UTC)

테이블이 방금 변경됨(모노북 사용)

모노북을 쓰는데 기본 셀 높이와 패딩이 바뀐 것 같다.글자의 글자 크기는 같아 보이지만, 확실히 셀이 더 크다.어디서 나에게 영향을 미칠 수 있는 변화가 일어났을까? -니체게덱 01:59, 2015년 2월 26일 (UTC)

벡터에서도 마찬가지야.또한, 글머리표상의 총알은 (미드닷처럼) 더 작고, 선을 수직으로 중심으로 하는 일반적인 큰 사이즈 대신 줄의 맨 아래에 있는 것처럼 보인다.임자디 1979 → 02:25, 2015년 2월 26일 (UTC)

OS와 브라우저를 주시겠습니까? -- [[User:Edokter]] {{talk}}10:21, 2015년 2월 26일 (UTC)

총알은 이제 PNG 대신 SVG가 되었다.iOS의 웹킷이 총알의 크기를 제대로 맞추지 못하는 한 가지 알려진 문제가 있다.웹킷 버그 리포트. -- [[User:Edokter]] {{talk}}10:28, 2015년 2월 26일 (UTC)

나는 MacOS X Yosemite(10.10.2)에서 Safari 버전 8.0.3을 사용하고 있다.파이어폭스(14.0.1 버전)는 탄환 크기 문제는 없지만 탄환들이 여전히 수직으로 약간 중심을 벗어나 있어 약간은 낮게 배치되지만 가 줄의 맨 아래에 있는 사파리처럼 낮지는 않다.크롬(v. 40.0.22214.115)에서 외형은 파이어폭스와 동일하지만 라인은 약간 낮다.발차기만을 위해 오페라(12.12절)도 찾아봤더니 크롬이나 파이어폭스와 똑같다.iOS 8.1.3을 실행하는 iPad의 Safari에서는 데스크톱에서 실행되는 Safari에서와 총알이 똑같아 보인다.임자디 1979 → 15:46, 2015년 2월 26일 (UTC)

@Edokter:윈도우 7과 파이어폭스 36을 사용하고 있다.총알이 다른 건 잘 모르겠고, 테이블 행의 추가 크기만 더하면 돼. -니체게덱 14:06, 2015년 2월 26일 (UTC)

@Imzadi1979 및 Niceguyedc:테이블 셀:.wikitable패딩이 늘었는데...반반으로 하다나는 이 커밋만 찾았지만, 이 변화를 논하는 부수적인 작업은 찾을 수 없다.(총탄은 벡터에만 영향을 미친다.) -- [[User:Edokter]] {{talk}}14:43, 2015년 2월 26일 (UTC)

응, 이전 패딩은 꽤 빡빡했어.testwiki에서는 예를 볼 수 있다.위키피디아 패딩.이 변화는 아무 것도 깨뜨리지 말았어야 했다.문제가 발견되면 여기에 링크를 제공하거나 Phabricator 작업을 파일화하십시오. --MZMcBride (대화) 15:50, 2015년 2월 26일(UTC)

shared.css의 리포지토리는 어디에 있지?카탈로그는 여전히 SVN에 연결되어 있고, git에서는 메인을 찾을 수 없다. -- Gadget850 ^talk 16:02, 2015년 2월 26일 (UTC)

[22] 이거?미디어위키 핵심 리포(foreverything it's on mediawo.글래셔(대화) 16:09, 2015년 2월 26일 (UTC)

고마워! 계속 참고하니까 {{shared.css}}}. -- Gadget850 ^talk 16:20, 2015년 2월 26일 (UTC)

이것이 영구적인 변화인가?나는 위키피디아에서 항상 테이블로 일하고 있는데, 이 변화에 꽤 화가 나 있어.더 큰 테이블은 더 이상 한 페이지에도 붙지 않는다.개인적으로 나는 테이블이 읽기 더 어렵고 깔끔하지 않아 보인다고 생각한다.테이블 세포를 원하는 크기로 만드는 방법도 없을까?Jahn1234567890 (대화) 00:45, 2015년 2월 27일 (UTC)

@Edokter와 MZMcBride: 나도 그 변화를 되돌려야 한다는 것에 동의한다 - Jahn1234567890의 지저분한 외모에 대한 메모는 잘 받아들여진다.또한 텍스트와 선 사이의 거리가 증가함에 따라 특히 시력 장애 때문에 확대해야 하는 것처럼 시각적으로 따라가기가 더 어렵다.마지막으로, 아이오와 주지사 목록 작은 테이블에서 dmeonstrainted한 것처럼 수직적 대 수평적 공백은 현재 불균형적이다.– 철학자^{Let us reason together.} 01:48, 2015년 2월 27일 (UTC)

6열 테이블을 포함하는 현저하게 넓은 infobox 요소를 통해 이 점에 유의하십시오.(우라늄 참조).상당히 넓어졌다.1. 상대적인 이미지 크기가 이제 바뀌었다는 것(즉, 절대적으로 변하지 않았다는 것)을 제외하면 나쁜 점은 아니며 이상적인 인포박스 폭("최대 33% 페이지 폭?")에 대한 지침이 있을 수 있다.인포박스는 이제 용서받지 못한 줄무늬가 줄었지만 공백은 점점 커지고 있다.나는 이것이 위대한 페이지 디자인 철학 안에 있기를 바란다. 2.그리고 나서 100% 페이지 너비가 모두 필요한 표를 확인하러 갔다. {{주기 표}}아무 영향도 없어, 왜냐하면 그것은cellpadding=세트(이것이 없다면, 넓은 패딩은 나쁘고, 원하지 않고, 쓸모없게 부서지고 있다.이것은 이러한 요점으로 이어진다: a) 셀패딩 세트가 없기 때문에 이러한 방식으로 영향을 받는 유사한 테이블(사용 & 100% 폭 필요)이 있는가? 그리고 b) 내가 기억한다면 셀패딩=은 더 이상 사용되지 않는다.비록 이것이 그것에 달려있지만 3. Btw, infobox의 패딩도 확대되었는가(대부분 섹션 헤더로 표시됨)?결론: 지금까지 깨진 것이 없고, 몇 가지 의문이 남는다. -DePiep (대화) 08:14, 2015년 2월 27일 (UTC)

{{주기 테이블}}}은(는) 사용하지 않으므로 영향을 받지 않아야 한다..wikitable구식 속성 때문이 아니다.나는 그 속성들을 적절한 CSS로 대체했다.-- [[User:Edokter]] {{talk}}09:34, 2015년 2월 27일 (UTC)

알겠다. (ws를 짜내야 했다.) -DePiep (토크) 10:45, 2015년 2월 27일 (UTC)

사용되지 않는 코드(이와 같이)가 나열되는 이 중심점은 무엇인가?나는 그런 진술들을 오락가락할 뿐이다. -DePiep (대화) 20:28, 2015년 2월 27일 (UTC)

위키백과:HTML5. SiBr₄ (대화) 21:09, 2015년 2월 27일 (UTC)

테이블 변경에 대한 나의 가장 큰 문제는 이것이 위키피디아 상의 모든 테이블에 영향을 미친다는 것이다.애초에 왜 바뀌었는지 이해가 안 돼.이전의 테이블 사이즈는 괜찮았다.그리고 패딩이 너무 작다면 너비를 스스로 조절할 수 있을 것이다.이제 당신은 선택의 여지가 전혀 없다.Jahn1234567890 (대화) 14:08, 2015년 2월 27일 (UTC)

응. 8px로 하는 게 어때? -DePiep (토크) 20:28, 2015년 2월 27일 (UTC)

안녕 Jahn1234567890.개인 사용자 CSS에서 위키 패딩을 경미하게 줄일 수 있다.일반적으로 늘어난 패딩이 더 잘 어울리는 것 같아.위 인용 사례(아이오와 주지사 목록#살아있는 전직 주지사 목록)가 보기 좋다. --MZMcBride (대화) 20:47, 2015년 2월 27일 (UTC)

이 공백의 문헌이 논의되는 중심적인 장소가 있는가?'내 생각엔..'좋아 보인다'는 것으로는 충분치 않다. -DePiep (토크) 20:52, 2015년 2월 27일 (UTC)

나는 중심적인 장소를 잘 모른다.testwiki:위키피디아 패딩은 내가 테스트를 했던 곳이다.아무것도 깨진 게 없고 늘어난 패딩(0.2em 대신 0.3em 0.4em)이 개선이라는 게 일반적인 공감대가 있는 것 같다.공백을 추가하면 가독성이 향상된다는 연구 결과가 꽤 있다.그게 더 좋은 주장이 아닐까? --MZMcBride (대화) 20:58, 2015년 2월 27일 (UTC)

길을 잃었다."나도 몰라", "아무것도 깨진 것 없어", "일반적인 공감대가 있는 것 같아" (어디서, 어디서, 어디서, 어디서, 어디서 반복하는지)이게 수업이 정해진 방식이라면, 왜 우리는 이야기를 하는 거지?무슨 상관이야.(그리고 당신이 여전히 나의 구체적인 요점을 설명하지 않았다는 것을 주지시켜 주겠다.8px로 만들어라. -DePiep (토크) 21:04, 2015년 2월 27일 (UTC)

@MZMcBride:Dave Marcis와 같은 결과 테이블의 경우, 변경으로 인해 이와 같은 테이블이 정말 지저분해 보인다.개인적으로 나는 이 변화에 대해 불만족스럽다. 왜냐하면 일반적으로 결과표를 보면 이 변화는 그러한 표들을 불필요하게 크게 만들기 때문이다.하지만 어떻게 내 개인 사용자 CSS에서 위키피디아 패딩을 줄일 수 있을까?나는 전에 이것을 가지고 일해 본 적이 없다.Jahn1234567890 (대화) 21:28, 2015년 2월 27일 (UTC)

잊기 전에.테이블 패딩이 변경된 이유는?그냥 원래대로 괜찮았다.내 말은 이 변화가 위키피디아에 모든 위키피디아에 영향을 미친다는 것이다.패딩을 두 배로 하는 것이 Jahn1234567890 (토크) 22:02, 2015년 2월 27일 (UTC)을 크게 바꾸는 방법이라고 생각한다.

(의견 없음) Hi. 게리트:188311은 관련 토론의 대부분을 포함한다.DePiep:8px를 제안하고 싶다면, 게리트 체인지셋이나 페이브리케이터 과제가 아마도 당신이 원하는 것일 것이다. :-) 또한 영어 위키피디아의 기술 마을 펌프는 기술적인 변화를 논의하기 위한 많은 장소들 중 하나에 불과하다.Jahn1234567890: 다음 코드(또는 유사한 코드)를 User에 추가하려는 경우:Jahn1234567890/common.css:

테이블.위키피디아의 > tr > th, 테이블.위키피디아의 > tr > td를, 테이블.위키피디아의 > * > tr > th, 테이블.위키피디아의 > * > tr > td를 {     패딩: 0; } 

도움이 되길 바라. --MZMcBride (대화) 22:28, 2015년 2월 28일 (UTC)

문제는 Jahn1234567890에만 있는 것이 아니라, 위키피디아에 있는 테이블들은 현재 모든 사람들에게 불필요하게 거대하다.(MZMcBride와 "그의 친구"만이 아닌) 이러한 사이트 전반을 변화시키자는 공감대가 형성된다면, 다음과 같은 새로운 클래스를 만들 수 있을 것이다.wikitablecompact낡은 0.2em 패딩을 사용하는 것이 창조되었는가?영향을 받는 테이블은 사용하지 않도록 다시 쓰일 수 있지만wikitable(각 개별 셀의 스타일을 수동으로 설정)을 함께 분류하면 큰 고통이 되고 불필요하게 혼란스러운 코드가 생성될 것이다. --Ahecht (TOKPAGE
) 18:25, 2015년 3월 1일 (UTC)

안녕 아헤흐트.늘어난 패딩을 거대하다고 표현하는 것은 좀 극단적인 것 같다.나는 위키피디브 컴팩트 같은 위키피디브 변형을 가질 것을 고려했지만, 사용 사례는 상당히 제한적인 것 같았다.이러한 변형을 로컬에서 사용하려면 MediaWiki를 수정하십시오.common.css.이 접근방식은 여기서 추가 클래스를 지원하기 위해 대안을 제안하고 현지 합의를 얻어야 한다. --MZMcBride (대화) 21:24, 2015년 3월 1일 (UTC)

@MZMcBride:아마도 패딩의 증가폭은 당신에게 크지 않지만, 나처럼 항상 테이블과 함께 일하는 사람에게는 그것은 큰 변화 그 이상이다.내가 위키피디아에 머무는 동안 만든 모든 결과표는 이제 압축되어야 할 때 크고 깔끔하지 않다.내 말은 내가 한 모든 일을 말하는 거야.그것은 나에게 모욕적인 느낌이다.나는 솔직히 왜 그렇게 패딩이 바뀌었는지 모르겠다.많은 사람들이 이 변화에 대해 전혀 기뻐하지 않는다.그리고 솔직히 말해서 나는 이 변화에 기뻐하는 사람들을 많이 보지 못했다.이것의 영향을 받는 많은 테이블에는 길이 있다(대부분은 그렇지 않다).이 변화에 대한 반대가 너무 많은 상황에서 이 변화를 유지하는 것은 불합리하다고 생각하기 때문에 이것을 해결할 방법이 있을 것이다.Jahn1234567890 (대화) 21:54, 2015년 3월 1일 (UTC)

어떤 설계나 사용자 인터페이스 변경은 부정적인 피드백을 이끌어낼 것이다.몇몇 사람들이 불만을 제기했고, 위에서 설명한 대로 사용자별, 사이트별 맞춤화 등 다양한 옵션을 이용할 수 있다. --MZMcBride (대화) 22:38, 2015년 3월 1일 (UTC)

• MZMcBride, 당신은 이 변경에 대해 계속 논의했다고 말하고 게리트 페이지를 언급한다.개발자만이 게리트 페이지를 읽는다.이것은 그것이 영향을 미치는 사람들 또는 프로젝트들과 논의되지 않았다.WMF 직원이 만든 수십만 페이지에 영향을 미치는 변화와 자원봉사 개발자가 만든 수십만 페이지에 영향을 미치는 변화는 실제로 차이가 없다. 두 가지 모두 실행 전에 영향을 받는 프로젝트 및 커뮤니티와 논의되어야 한다.기본적으로, 내가 여기서 보는 것은 한 자원봉사 개발자가 그가 생각하기에 멋진 아이디어를 생각해 내고, 개발자 스트림 밖에서 그 제안서를 누구와도 논의하지 않고 WMF 프로젝트에 그것을 적용하고 분배할 수 있는 연결고리를 가지고 있다는 것이다.그것은 WMF 직원이 취했을 때, 당신이 스스로 결정했던 행동의 유형이다.너한테 더 좋은 걸 기대했을 텐데.위험원 (대화) 22:57, 2015년 3월 1일 (UTC)
  • 안녕 레이져.이론적으로 MediaWiki core에 대한 어떤 변화도 수백만 페이지에 영향을 미친다...나는 너의 요점을 모르겠다.

    전체적으로 늘어난 패딩이 더 잘 어울린다.800개 이상의 Wikimedia Wiki(Wikimedia MediaWiki Wiki가 아닌 수천 개의 Wiki 외에)에서 이와 같은 변화에 대해 논의할 제안이 있다면 공유하십시오.해결해야 할 특정 기술 문제가 있는 경우 공유하십시오.

    사실, 당신은 약간의 패딩 증가는 광범위한 지역사회 협의가 필요하다고 주장하는 것 같은데, 이것은 꽤 미친 짓인 것 같다.정말 개발이 그렇게 되거나 되어야 한다고 생각하십니까? --MZMcBride (대화) 23:04, 2015년 3월 1일 (UTC)

    • 아니, MZM, 내가 기대하는 것은 변경의 영향과 변경에 의해 영향을 받게 될 그룹에게 그 변화를 완화시키기 위해 그들이 할 수 있는 방법의 분석이다.이것은 특히 그 어느 곳에서도 요구되지 않았고 본질적으로 단일 개발자의 바람과 욕구인 주관적 변화에 관해서도 중요하다.위험원 (대화) 23:14, 2015년 3월 1일 (UTC)
      • 글쎄, 나는 여기서 제기되는 질문과 우려에 대응하여 자원봉사에 시간을 보내고 있어. :-) 이 경우, 통지나 비상계획의 방식에는 별로 도움이 되지 않을 정도로 변화가 작거나 경미했다.예상 파손은 없었으며, 사용자에게 미치는 영향은 무시할 수 있는 것으로 간주되었다. --MZMcBride (대화) 23:26, 2015년 3월 1일 (UTC)
      • 안녕 @MZMcBride:답장 고마워.CSS 페이지에서 작업하는 방법을 알아냈어.하지만 왠지 패딩이 바뀌기 전처럼 피부를 가질 수가 없어.나 좀 도와줄래?Jahn1234567890 (대화) 23:22, 2015년 3월 1일 (UTC)
        • 특수:Permalink/649445826은 괜찮아 보인다.아마 그쪽으로 돌아가야 할 것이다. --MZMcBride (대화) 23:28, 2015년 3월 1일 (UTC)
    • 미안하지만, 나도 그가 변하는 것에 반대해. 0.2em에서 0.4em이 두 배로 늘어나고 있어. "빛"이 아니라. 그게 보여.적어도 페이브리케이터에서 그러한 시각적 영향을 미치는 어떤 변화도 논의되었어야 했다.인식된 개선은 주관적이며 이러한 변화를 촉발하는 전제가 없었다. -- [[User:Edokter]] {{talk}}23:26, 2015년 3월 1일 (UTC)
      • 사과할 필요 없어, 의견 차이는 괜찮아.그리고 Cascading Style Sheet의 특성은 개별 사이트 또는 개별 사용자가 기본 패딩을 재정의하거나 파생 CSS 클래스를 만들어 자신의 경험을 사용자 정의할 수 있도록 한다.이러한 변화를 촉발시킨 전제가 있었고 게리트:188311. --MZMcBride (대화) 23:32, 2015년 3월 1일 (UTC)
        • 그럼 미디어위키에서 이 위키에서 0.2em으로 다시 설정해 봅시다.Common.css 그럼? -- WOSlinker (대화) 09:19, 2015년 3월 2일 (UTC)
          • 나는 그렇게 하고 싶다.나 또한 과제를 제기하여 되돌리려고 노력할 것이다. -- [[User:Edokter]] {{talk}}10:09, 2015년 3월 2일 (UTC)
        • '더 좋아 보인다'는 전제는 크게 논쟁거리가 되지 않으며, 그것이 발동한 플랙을 고려하면 임팩트에 대한 연구는 부실했다.사용자를 개인 CSS로 보내서 이러한 성격의 변경을 '해제'할 수 없다.더욱 곤란한 것은 테이블이나 템플릿에서 실행을 취소하려면 모든 테이블 셀에 인라인 CSS가 필요하다는 점이다. -- [[User:Edokter]] {{talk}}10:09, 2015년 3월 2일 (UTC)

(un-indent) 에러, "flack"은 꽤 관대한 용어다.어쩌면 반나절이나 되는 사람들이 의견을 냈을지도 모르는데, 이것은 아마도 게리트 변화를 검토한 사람들의 수와 거의 맞먹을 것이다.직접 편집하지 않는 것이 가장 좋았을지도 몰라혹시 다른 위키에서 위키 패딩의 이러한 변화를 눈치채거나 신경 쓴 적이 있는지 아십니까?만약 반대 의견이 영어 위키피디아에 특정된다면, 지역적 오버라이드는 아마도 최선의 선택일 것이다.또는 0.2em 0.4em. :-) --MZMcBride (대화) 05:17, 2015년 3월 4일 (UTC)

만약 이 논평들이 페이브리케이터에 첨부되었다면, 그것은 -2'd (거부) 되었을 것이다.이런 '미미한' 변화가 댓글을 만든다면 대체로 좋지 않은 생각이다.위의 언급들은 모두 장점이 있지만, 나는 당신이 그 중 한 가지를 말하는 것을 본 적이 없다. 즉, 왜 "그게 더 보기 좋다"는 것인지 설명할 수 없다.그것은 주관적이고 측정할 수 없는 기준이며, 그 자체는 절대적으로 논란의 여지가 없는 한 변화의 좋은 이유가 될 수 없다.그것은 여기에 해당되지 않는다.제발 모든 논평이 무관하다고 치부하지 마라; 그것은 당신이 단지 그것들을 무시하는 것처럼 보이게 만든다. -- [[User:Edokter]] {{talk}}2015년 3월 4일 09:00(UTC)

MZ의 방어에서, 그는 비주관적인 이유를 제시했는데, 그것은 백색 공간에 대한 작은 증가(단일 문자 폭의 5분의 1 절대 변화)가 가독성을 향상시킨다(평균 독자의 경우, 평균 콘텐츠).

더 생산적인 대화를 나누면 다음과 같은 것이 될 것이다.모든 셀에 CSS 태그를 설정하지 않고도 평균 테이블의 가독성(더 많은 화이트 스페이스)과 다른 테이블의 상식(예: 단일 숫자만 포함하는 셀의 경우 더 적은 화이트 스페이스)을 모두 수용할 수 있도록 wikitext 테이블 설정에 필요한 변경 사항은?WhatamIdoing (talk) 19:47, 2015년 3월 4일 (UTC)

에독터:내 생각에 이 대화는 정말 진절머리가 난 것 같아.너의 논평은 끔찍하게 틀렸지만, 사실 언급할 가치가 없다.당신은 이제 당신이 선호하는 패딩을 영어 위키피디아에 부과했다; 미디어위키는 그냥 둘 수 있을 것 같다. --MZMcBride (대화) 21:36, 2015년 3월 6일 (UTC)

끔찍하게 틀렸나?당신은 어떤 논의도 무시한 채 급격한 변화를 가했지만, 그것은 좋은 평가를 받지 못했다.무엇을 기대하셨나요? -- [[User:Edokter]] {{talk}}00:01, 2015년 3월 7일(UTC)

게리츠에서 토론이 있었는데, 너는 단지 그 장소를 승인하지 않을 뿐이야.당신이 나를 구체적으로 비난함으로써 이 토론을 개인화하려고 하는 동안, 나는 이 변화를 제안했을 뿐이다.나는 이 변화를 병합하지도 않았고 이 변화를 배치하지도 않았다.그리고 나는 이 변화가 800개가 넘는 다른 위키미디어 위키에서 좋은 평가를 받은 것처럼 보인다는 것을 반복할 것이다.내가 알 수 있는 한 위키에 있는 몇몇 사람들은 그 변화에 동의하지 않는다.

나는 너를 직접적으로 외치는 것을 피하려고 노력했지만, 이 전체 토론에서 나는 네가 (개인적으로) 이 변화에 대해 상담받지 못한 것에 대해 대부분 화가 난다는 강한 느낌을 받았다.그리고 그것은 나에게 좀 옹졸해 보인다.당신의 지역적 오버라이드도 같은 사고방식을 암시하는 것 같다.정말 다른 로컬 관리자도 동의할 수 없으십니까?이미 토론에 참여하고 분명히 갈등을 빚었을 때 이 패딩의 변화를 스스로 되돌릴 필요가 있다고 느꼈나?여기서 당신의 행동은 "나는 자문을 받지 않았다!" "자문을 받지 않은 곳의 변화에 반대한다!"라는 모든 취향을 가지고 있다. --MZMcBride (대화) 15:40, 2015년 3월 7일 (UTC)

개인적으로 당신을 탓하는 게 아니에요...나는 이 변화로 과정의 결백을 폭로하려고 한다.하지만 너는 이것을 개인적으로 받아들이는 것 같다.나는 당신이 변화를 옹호하기 위해 나섰고, 모든 불평과 논쟁들을 체계적으로 존재하지 않는 것으로 치부했기 때문에 당신에게 말하는 것이다.그리고 내가 설득당하지 않은건 상관없어...아무도 자문을 받지 않았다!나는 단지 불평에 응했을 뿐이다나는 네가 무엇을 "잘 받은" 것으로 정의하는지 모르겠다. 그 예를 들어봐라.그 동안, 나는 단지 실제 첸지에 대해 토론하기 위해 맛을 열 것이다. -- [[User:Edokter]] {{talk}}17:52, 2015년 3월 7일 (UTC)

글머리 기호

예를 들어, 이 AFD 위키피디아를 보면:삭제/New Downs에 대한 기사들 - 그것들이 아주 작은가?,
사진에서 볼 수 있듯이 나한테는 너무 작아서 여기 뭔가 바뀌었는지 아니면 내 노트북/크롬 설정과 관련이 있는지 잘 모르겠어.
고마워, –Davey2010^Talk 03:33, 2015년 2월 27일 (UTC)

그것들은 나에게 보통 사이즈로 나타난다.— 미스터 스트라디바리우스^{♪ talk ♪} 03:35, 2015년 2월 27일 (UTC)

#Tables 막 바뀐 (모노북을 사용한) Tables의 상단에 이것에 대한 논의가 있다.– 철학자^{Let us reason together.} 03:40, 2015년 2월 27일 (UTC)

스트라디바리우스 씨께 감사드리며

철학자 - 실제로 크롬 문제인 것 같아? IE를 시도해 봤는데 정상인데 크롬 로그아웃을 시도해도 작은 것 같아, 폰트 설정이 모두 정상이야, 모든 걸 지워버리고 속임수가 되는지 볼게, –Davey2010^Talk 03:46, 2015년 2월 27일(UTC)

벡터 사용한다고 말하는 걸 깜빡했네. 어쨋든 아니, 다 똑같아. 모노북 문제가 부분적으로 있는 것 같은데...Vector에서, Ah well hell anyway ) –Davey2010^Talk 04:44, 2015년 2월 27일 (UTC)

이것은 웹킷 문제인데, 크롬은 작년에 (블링크에서) 고쳤기 때문에, 그것은 문제가 되지 않을 것이다. -- [[User:Edokter]] {{talk}}09:43, 2015년 2월 27일 (UTC)

안녕 Edokter - 아니, 내가 아는 한 최신 버전을 사용하고 있어(34.0.1847.116), 고마워, –Davey2010^Talk 17:35, 2015년 2월 27일(UTC)

Davey2010, 그건 오래된 일이야!최신 버전은 40이다. -- [[User:Edokter]] {{talk}}17:47, 2015년 2월 27일 (UTC)

네, 위 파이어폭스의 #New CSS에서 언급했듯이 Chrome 40.0.22214.115m는 현재 버전 입니다. --Redros64 (토크) 17:51, 2015년 2월 27일 (UTC)

에독터, 정말?세 개의 막대가 녹색으로 변하는 순간 크롬을 업데이트하고 있었는데, 도대체 어떻게 업데이트 버전을 사용하던 것에서 오래된 버전으로 바꿀 수 있었을까?...내가 모르게 크롬이 꽤 오랫동안 업데이트되지 않은 거라면?난 정말 싫어! 어쨌든 미스터리를 풀어줘서 고마워 ) –Davey2010^Talk 18:13, 2015년 2월 27일 (UTC)

보아하니 2014년 4월 이후로 내 브라우저가 업데이트되지 않았어...대단해!어쨌든 도와줘서 고마워 :) –Davey2010^Talk 18:24, 2015년 2월 27일 (UTC)

OS X Yosemite의 Safari 8(Wikipedia 홈 페이지)

Android 5.0의 Chrome 40.0.2214(TouchWiz)

OS X 10.10.2의 Safari 8.0.3(최신 버전)에도 동일한 문제가 있음(오른쪽 스크린샷 참조)총알 포인트는 풀 스톱과 크기와 위치가 거의 같다.이기적인 해마 (토크) 13:40, 2015년 3월 1일 (UTC)

내 갤럭시S5(SM-G900V)에서 안드로이드 5.0을 실행 중인 안드로이드용 크롬 40.0.214.109에서도 같은 문제가 발생했다.정말 짜증나, 왜냐하면 그 기간들이 엉망진창인 것처럼 보이기 때문이야.EoRdE6^{(Come Talk to Me!)} 19:25, 2015년 3월 6일(UTC)

탁구

{{ping}}}}{{ping}}}}}}}}{pong}}}}에 매우 가깝기 때문에, 나와 O는 QWERTY 키보드에 매우 가깝기 때문에 흔히 하는 오타로서 나는 흔하게 인정하고 말겠다.

제안: 이 사실을 유머러스하게 활용하기 위한 허영심 템플릿.

예를 들어 @ 레거시 마리오: 또는 @Mr. Stradivarius: (레거시 마리오: 또는 @Mr. Stradivarius:) ResMar 21:01, 2015년 3월 6일 (UTC)

스트라디바리우스에게 그를 실험용 기니피그로 사용한 것에 대해 미리 사과하라!ResMar 21:02, 2015년 3월 6일 (UTC)

Pong (동음이의)은 다음과 같이 말한다: "Pong, 컴퓨터 네트워킹 전문 용어로, ping에 대한 응답".응답 대신 pong을 ping의 동의어로 사용하면 혼란스러울 수 있지만 ping을 한 사용자에게 알릴 때 사용할 것을 제안하는 문서를 만들 수 있을 것이다.탁구 스키마를 참조하십시오.<피던트 경보>는 내가 '퐁당'하는 데 사용할 수도 있었지만, 당신은 이미지를 공개 도메인으로 릴리스하지 않았으므로 귀인이 필요하며 당신의 템플릿은 파일 페이지에 연결되지 않는다.</페던트 경보> 프라임헌터(토크) 21:32, 2015년 3월 6일 (UTC)

@PrimeHunter:아, 미안, 파일:퐁볼은 비행중이야. svg가 바로 그거야, 내가 지금 퍼브해놨어.이미지를 반전시키는 것은 그리 어렵지 않을 것이다(필요한 경우 템플릿의 반대쪽에서 호스트).ResMar 23:42, 2015년 3월 6일 (UTC)

샌드박스를 풀어주기 위해 이 토론에서 내 템플릿을 제거했어, 미안, 헤헤ResMar 04:46, 2015년 3월 10일(UTC)

고유하지 않은 섹션 제목 문제

(WP:Village pump (기술)/Archive 126#Wipedia 기사 섹션 링크 참조)

섹션 제목이 독특하지 않을 때, TOC는 여전히 정상 작동하며, 두 번째 섹션은 #앵커 링크에 _2; 세 번째, _3 등을 추가한다.

하지만 그 시스템은 내가 알고 있는 다른 두 가지 상황에서 실패한다.

섹션을 편집하면 WP가 /* title섹션 제목 > */로 편집 요약을 미리 작성하는데, 이 내용은 섹션에 대한 링크→로 바뀐다.섹션 이름이 독특하다면 이 작업은 훌륭하다.그러나 WP는 충분히 똑똑하지 않기 때문에, 2번째 섹션이나 동일한 이름의 섹션에 있는 편집의 요약에는 오해의 소지가 있는 → 같은 이름으로 첫 번째 섹션에 연결되는 링크가 포함될 것이다.

또한 섹션 편집을 완료한 후 WP는 편집 중인 섹션의 시작 부분으로 자동 스크롤한다.이 역시 섹션 이름이 고유하지 않을 때 실패한다.두 번째 섹션을 편집하면 첫 번째 섹션의 시작 부분으로 스크롤된다.

예를 들어, 금속, 금속 및 비금속의 속성이라는 글에서 첫 번째와 세 번째 섹션은 평행 하위 섹션 이름을 가지고 있다.

• §§§ 공유 특성, 금속, 메탈로이드 및 비금속
• §§§ Anomalous 특성, Metals 2, Metalids 2, Nonmetals 2

이 인체모형을 2차 금속 섹션으로 편집하게 했을 때 WP는 /* Metals */로 편집 요약을 미리 채웠고, 이 편집 요약을 1차 금속 섹션으로 가리키며 →로 변경했고, 편집을 저장하자 브라우저가 1차(2차 금속 섹션이 아닌) 금속 섹션으로 스크롤했다.

이게 버그리스트에 들어갔나?YBG (대화) 07:03, 2015년 3월 9일 (UTC)

응, 2004년에.이 문제들은 각각 T4831과 T211이다.마트마 렉스톡스 08:37, 2015년 3월 9일 (UTC)

X!'의 도구가 작동하지 않음

https://tools.wmflabs.org/xtools-ec/?user=Anthonyhcole&project=en.wikipedia.org을 참조하십시오.

모든 사용자 "공헌 페이지" 하단에 연결된다. --Anthonyhcole (대화 · 기여 · 이메일) 13:29, 2015년 3월 9일 (UTC)

• Anthonyhcole, Xtools는 실행 중인 것 같지만, 보아하니 db lag나 다른 db 문제가 있는 것 같다(그래서 db에서 돌아오는 데이터는 없고 0s로 보고하고 있다).xtools가 실험실 문제에 대해 할 수 있는 일은 많지 않아, 미안해.—{{U Technical 13}} (e • t • c)14:34, 2015년 3월 9일 (UTC)

기술 뉴스: 2015-11

15:19, 2015년 3월 9일 (UTC)

stats.grok.se 또 고장났나?

웹사이트는 지난 5일 이후 업데이트되지 않았다.기존에는 당일 페이지뷰가 다음 날 가능했다.하지만 5일 동안 업데이트는 없었다.

또한 Wikimedia Labs에서 백업용으로만 사용할 수 있는 병렬 툴을 생성할 때가 되었는가?나루톨로베히나타5 23:11, 2015년 3월 9일 (UTC)

https://tools.wmflabs.org/#toollist-liviviewstats에는 이미 다른 도구가 있지만, 적어도 내가 확인할 때마다 그것은 완전히 다운되었다.나는 그것에 대한 일이 있는지 계획이 있는지 모르겠다.프라임헌터(토크) 01:11, 2015년 3월 10일 (UTC)

Infobox Person 억제

안녕, 누가 내 선호에 템플릿 억제 코딩 좀 해줄래?기사의 Infobox 사람 및 ifobox에 있는 사진을 250px로 설정된 포맷된 사진으로 infobox에 있는 사진을 infobox?infobox에 제공된 캡션으로 대체하는 것(UTC)

@블루펠트 박사: 나는 전체 사람의 전모를 억누를 줄 안다.{{infobox person}}-그것은

테이블.인포박스.전기의 { 전시하다: 없는; } 

특수:MyPage/common.css - 하지만 이미지를 어떻게 다시 교체해야 할지 모르겠다.나는 Javascript가 필요하다고 생각한다. --Redros64 (대화) 13:37, 2015년 3월 7일 (UTC)

안녕, 블로펠드 박사님{{Infobox person}}}을(를) 사용하는 기사의 구체적인 예와 억누르려는 구체적인 이미지를 제공해 주시겠습니까?이 infobox(또는 다른 infobox)를 사용하는 기사의 예와 억제하지 않으려는 이미지의 예도 제공해 주시겠습니까?

이것을 하기 위해서는 작은 자바스크립트 스크립트가 필요할 것이다.테스트 사례 목록을 갖는 것은 그러한 스크립트를 개발하는 데 큰 도움이 될 것이다.

마지막으로, 자연적인 인포박스 이미지를 대체할 이미지("형식 사진")에 대한 링크를 제공하시겠습니까? --MZMcBride (토크) 15:52, 2015년 3월 7일 (UTC)

안녕, 둘 다 응답해줘서 고마워.기본적으로 인포박스 대신 250px로 표준 [39].인포박스 건축가는 현재 인포박스 사람에게 먹이를 주고 있지만 인포박스 건축가에게는 효과가 있을지 확실치 않다.기본적으로 내가 생각하기에 그런 중복적인 인포박스가 있는 모든 예술 전기 기사에서는 나는 그것을 억제할 수 있고 그 대신에 깨끗한 사진을 갖고 싶다.예를 들어 안젤리나 졸리는 자신의 이미지를 250px에 캡션으로 표시하기 위해 가족에게 트라이비아를 주는 인포박스 대신에 자신의 이미지를 인포박스에 표시하는 것이다.만약 어떤 것이 인포박스의 이미지 파라미터를 먹고 그 이미지를 그냥 거기에 놓을 수 있다면, 그렇게 할 수 있을까?if image(인포박스 사용자 또는 건축가, [File:xxx.jpg 엄지 250px 캡션=] 표시...〇 블로펠드 박사 17:31, 2015년 3월 7일 (UTC)

일부 css 클래스가 템플릿에 추가된 경우 javascript 없이 수행될 수 있다.Infobox person, 의 선에 따라 무엇인가가 있는

테이블.인포박스.전기의 tr { 전시하다: 없는; } 테이블.인포박스.전기의 tr.주상, 테이블.인포박스.전기의 tr.주상감각색. { 전시하다: 식탁의 노를 젓다; } 

. — Cryptic 01:57, 2015년 3월 8일 (UTC)

브래드 피트와 안젤리나 졸리에게 이런 일이 일어나는 것 같다.

$('.infobox tr').각각(기능을 하다() { $(이).아이들.(":not([colspan='2])").부모().css('표시', 'none') }); 

버락 오바마와 같은 더 복잡한 경우 이 접근법도 효과가 없을 것이다.이 억제를 어떻게 언제 촉발할 것인지도 명확하지 않다. --MZMcBride (대화) 06:19, 2015년 3월 8일 (UTC)

infobox.person { display: none; }은(는) 내게 효과가 없었다.조름(WMF)과 같은 재단과 개발자들은 인포박스에 대한 분쟁이 이곳에서는 매우 흔하다는 것을 인정하고, 위키피디아를 전기에서 억압함으로써 보다 융통성 있게 만들어야 할 때라고 나는 생각한다.아마도 이들을 위키 자료로 집중화하려는 의도일 것이다.만약 그들이 그렇게 한다면, 사용자들 사이에서 특정한 것을 억압할지 여부를 선택할 수 있는 옵션이 있어야 한다.당분간은 그냥 무시하면 될 것 같아.어쨌든 고마워.1985년 3월 8일 블로펠드 박사 11시 39분 (UTC)

그러한 논쟁은 아주 아주 작은 비율의 기사에 대한 토론에서 일어나며, 많은 편집자들이 전혀 관여하지 않는다.대부분의 편집자들, 그리고 대부분의 독자들은 인포박스의 포함을 환영하는 것 같다.재단은 그런 난해한 요구에 시간과 노력을 낭비하는 것은 어리석은 일일 것이다.Andy Mabbett (Pigsonthewing); Andy와 대화; Andy가 편집한 20:35, 2015년 3월 8일 (20:35, 8)

나는 네가 앤디를 놀리려고 하는 사람이 누구인지 모르지만, 내가 지난 2년 동안 관계된 거의 모든 기사들은 그들에게 부과되거나 부과되려고 시도된 Infobox를 가지고 있다.나는 그들을 옹호하는 사람들이 기사 전반에 걸쳐 일관성을 보이고 인포박스를 균일하게 만드는 것을 좋아한다는 것을 존중하지만, 당신은 그것을 다른 관점에서 보지 않고, 오만한 IDONTLICKIT의 주장으로 당신과 동의하지 않는 사람을 총살하는 버릇이 있다.전기에서 그들을 혐오하는 경험 많은 편집자들이 분명히 여기에 있다.이것은 매우 현실적인 문제인데, 토크 페이지의 논쟁은 종종 몇 주 동안 계속된다.사실, KJP1은 최근 그가 인포박스 분쟁에 투입된 시간 낭비와 열정이 기사를 쓰는 데 사용될 수 있을 때마침 기사 작성에 이용될 수 있었다.그가 맞아.그것은 절대 그것에 도달해서는 안 된다.모든 사람이 반드시 infobox를 가지고 있고 그것을 좋아한다고 가정하기 보다는, 각 편집자를 위한 페이지를 사용자 정의할 수 있는 선택권이 있어야 한다.그리고 그것은 단지 infooboxs를 의미하는 것이 아니라, 사이드바를 억제하기 위해 읽을 때 전체 페이지 옵션과 같은 옵션들을 의미하며, 독자들이 원하는 모양을 만들 수 있는 훨씬 더 광범위한 도구들을 의미한다.모든 사람은 다르다.18 2015년 3월 9일 블로펠드 박사 10시 40분(UTC)

나는 다른 사람을 놀리려고 하는 것이 아니니까 제발 내 동기를 의심하지 마."지난 2년간 실질적으로 모든 특집 기사[당신]가 관련되었다"라는 세트는 우리의 모든 기사들의 집합이 되거나 심지어 그것을 대표하는 기사들과도 거리가 멀다.마찬가지로, 당신과 당신이 언급하는 다른 편집자들은 우리의 모든 독자들을 대표하기는커녕 우리의 모든 편집자들을 대표하지 않는다.내 주장은 (다른 사람들의 "혐오"와는 달리) IDONTLYKIT이 아니다; 나는 infobox가 이로운 이유를 긴 시간, 그리고 뒷받침되는 증거와 함께 설명했다.Andy Mabbett (Pigsonthewing); Andy와 대화; Andy가 편집한 2015년 3월 11일(UTC)

하지만 블로펠드 박사님, 이걸 붙여보십시오.

table.infobox.prow tr {display:display;} table.infobox.prow tr:first-of-type + tr {display:table-row;}

common.css - User:Dr.에서 찾으십시오. 블로펠트/common.css

나는 그것이 모든 전기에서 작동해야 한다고 보장하지는 않는다-그리고 그것은 오래된 브라우저에서는작동하지 않을 것이다.하지만 그것은 당신에게 위키 라이프를 조금 더 견딜 만하게 만들지도 모른다.정말 도움이 되었으면 좋겠다. --RexxS (대화) 22:41, 2015년 3월 8일 (UTC)

RexxS 고마워!효과가 있는 것 같아!사진 주변에 상자 윤곽선을 제거하는 방법은 없을까?1915년 3월 9일 블로펠드 박사(UTC)

예, 새 줄을 추가하십시오.

table.infobox.properties {border:properties;}

사용자:Dr.의 다른 라인 아래 블로펠드/공통.css.완벽하지는 않겠지만, 당신이 요구하는 것에 가깝다.테두리가 희미해지길 바란다면table.infobox.biography {border:1px solid #EEE;}대신. --RexxS (대화) 20:31, 2015년 3월 9일 (UTC)

@ Bloomfeld 박사: 2015년 3월 8일 11시 39분 당신의 게시물에서 이 버전을 의미한다고 가정하면 - 아니, 그것은 당신(또는 다른 누구에게도) 효과가 없었을 것이다.infobox.person유효한 선택기가 아님: 다음과 같은 HTML 요소가 없음<infobox>...</infobox>그리고 비록 있었다고 해도, "사람"은 위키피디아 전기 페이지에서 사용되는 클래스가 아니다.위의 CSS blobs를 보면, 항상 "infobox"라는 단어 앞에 점이 있는데, 이 점은 당신의 브라우저에 "infobox"는 요소가 아니라 클래스라고 알려준다.구두점은 선택사항이 아닌 CSS에서 중요하다.첫 번째 예에서는 셀렉터를 사용했는데table.infobox.biography그 말은 'HTML'이라는 뜻이다.<table>...</table>"인포박스" 등급과 "생물학" 등급이 있는 요소 --Redros64 (토크) 23:44, 2015년 3월 8일 (UTC)

이 섹션 뱀에 연결

토론 섹션의 머리 부분에서 "이 섹션으로 연결되는 링크"라는 메시지를 가진 두 마리의 뱀을 본 사람은 나뿐인가요?굿데이 (토크) 00:46, 2015년 3월 5일 (UTC)

최근에 추가된 구간 표지판이야.CSS에서 이를 제거하십시오.

 .mw-dmp {display: none

프라임헌터 (대화) 00:59, 2015년 3월 5일 (UTC)

이해가 안 돼굿데이 (토크) 01:02, 2015년 3월 5일 (UTC)

@GoodDay:도움말에 도움말 페이지:사용자 스타일.간단히 말해서, 사용자: 페이지를 만드십시오.GoodDay/common.css 및 Prime이라는 코드를 추가하십시오.헌터가 너한테 줬어그러면 뱀들은 사라질 것이다.— 미스터 스트라디바리우스^{♪ talk ♪} 01:11, 2015년 3월 5일 (UTC)

나는 그것을 쇼 프리뷰로 테스트했고 그 코드가 내 계정을 손상시킬 것이라는 경고를 받았다.굿데이 (토크) 2015년 3월 5일 01:12, 5 (UTC)

• 당신이 모르거나 신뢰하는 코드는 그렇게 할 수 있다.경고는 만약 그것이 악성 코드였다면, 당신의 계정을 손상시킬 수 있다는 것이다.— Chrisco 1492 (대화) 01:14, 2015년 3월 5일 (UTC)

나는 쌍뱀을 참아야 할 것 같아.나는 미지의 영역으로 모험하는 것에 대해 까다롭지 않다.굿데이 (토크) 01:16, 2015년 3월 5일 (UTC)

개인 JS와 CSS 페이지에 추가하는 것을 조심하는 것이 좋지만, 이 경우에는 코드가 안전하므로, 이번에는 그렇게 해서 단념하지 마십시오.— 미스터 스트라디바리우스^{♪ talk ♪} 01:29, 2015년 3월 5일 (UTC)

아마도 구간 표지판을 훼손한 사람들은 결국 철거를 선택할 것이다.스스로 그렇게 하는 것은 나에게 너무 위험하다 :) Good Day (토크) 01:47, 2015년 3월 5일 (UTC

이 코드는 완벽하게 무해하며 WP에서도 거의 동일하다.CSHIDE. 당신의 JS와 CSS 페이지는 빈 페이지를 미리 볼 때에도 항상 표준 경고를 보여준다.Stradivarius씨와 나와 같은 관리자들은 실제로 MediaWiki에 코드를 올릴 수 있다.Common.js 및 MediaWiki:Common.css는 영어 위키백과 페이지를 보는 모든 사용자 또는 최소한 브라우저에 자바스크립트와 CSS가 있는 사용자가 자동으로 실행한다.관리자는 또한 개인 JS 및 CSS 파일을 편집할 수 있지만, 사용자가 요청하지 않는 한, 또는 다른 사용자가 공유하지만 유지 관리하지 않는 사용자 스크립트를 작성한 경우 거의 편집하지 않을 수 있다.프라임헌터 (토크) 01:59, 2015년 3월 5일 (UTC)

우리는 정말로 "이 페이지에 삽입하는 코드" 메시지에 대해 뭔가 조치를 취해야 한다. 그것은 너무 많은 걱정을 야기하고, 그것은 몇 달마다 발생한다.2009년 2월 27일, 2010년 7월 13일, 2011년 10월 15일, 2011년 11월 27일, 2011년 12월 9일, 2012년 11월 1일, 2013년 6월 2일, 2013년 7월 8일, 2014년 1월 2일, 2014년 4월 3일, 2014년 4월 8일, 2014년 6월 20일, 2014년 9월 13일, 2014년 10월 19일 참조.미디어위키에서 열린다.Jswarning 및 MediaWiki를 통해 사용자 CSS 페이지에 표시됨:Usercsspreview.미디어위키에서 이 문제에 대한 마지막 논의는 다음과 같다.Jswarning은 3년 전에 끝났다. --Redrose64 (대화) 13:45, 2015년 3월 5일 (UTC)

나는 뱀에 대한 묘사를 좋아한다! 하지만 §는 (법률상 법정 부분을 나타내기 위해 사용되는) 섹션 간판이다.어쨌든, 우리가 개인 CSS를 통해 어떻게 그것을 제거했는지, 혹은 선택했는지 등이 아니라, 애초에 왜 이런 변화를 어디에서나 만들어 내는 것이 좋은 생각이었는지, 그리고 그것이 세계적인 변화로 제거되어야 하는지에 대한 논의는 어디서든 아는 사람이 있는가?---Fuhgetaboutit (토크) 01:42, 2015년 3월 5일 (UTC)

그리고 호기심에서, 이것의 목적은 무엇인가?TOC로 올라가지 않고 섹션에 링크를 쉽게 복사할 수 있는 방법을 제공하려면 클립보드로 바로 이동하면 멋질 것이다(예, 일부 브라우저 구현이 이에 대해 편집증적인 것으로 알고 있다).안녕, 오렌지 스웨이드 소파 (토크) 02:00, 2015년 3월 5일 (UTC)

패브릭케이터: "mw-headline-앵커"를 검색하면 다음과 같은 결과가 나왔다.T18691. 프라임헌터 (토크) 02:05, 2015년 3월 5일 (UTC)

@GoodDay: 무슨 의미라도 있다면, 위의 코드를 내 CSS 페이지에 추가했을 뿐인데, 그것은 효과가 있었어, 뱀은 더 이상 안 돼! - JuneGloom07토크 02:27, 2015년 3월 5일 (UTC)

나는 내 일에 신경 쓰지 않을 것이다.굿데이 (토크) 02:29, 2015년 3월 5일 (UTC)

위키에 뱀이 있다고?러그넛 07:44, 2015년 3월 5일 (UTC)

중요한 것은 링크를 비활성화하는 CSS 코드가 내 화면 판독기 JAWS에서 작동하지 않았다는 것이다. css 또는 monobook.css; 그런 코드는 보통 의도된 대로 작동하지만, 아마도 제목에 있다는 사실이 화면 판독기를 혼란스럽게 했다.JAWS의 플렉시블 웹 기능(섹션 링크를 비활성화하기 위해 CSS 클래스로 요소를 숨기도록 지시하는 기능)을 사용해야 했다.Graham87 09:29, 2015년 3월 5일 (UTC)

죠스? 더 큰 위키가 필요해러그넛 09:51, 2015년 3월 5일 (UTC)

원래의 q로 돌아가려면(예: 뱀에 관한 일) 위키백과에서 링크된 페이브릭커 티켓을 확인하십시오.Manual of Style/Accessibility/Archive 13#Impended MediaWiki 기능으로 화면 판독기 사용자의 접근성에 영향을 미친다.이 티켓은 2008년 12월에 인상되었지만, 당신은 알려졌지만, 여전히 나에게 불분명한 이유로 2015년 2월 16일 이전에 읽지는 못할지도 모른다. --Redros64 (토크) 12:20, 2015년 3월 5일 (UTC)

Bugzilla url은 https://bugzilla.wikimedia.org/show_bug.cgi?id=16691이었을 것이다.구글 검색 결과 http://wikibugs-l.narkive.com/5RSNaeK4/bug-16691-new-section-headings-should-have-some-clickable-anchor-for-passing-links이 나왔다.프라임헌터 (대화) 2015년 3월 5일 13시 30분 (UTC)

기록상으로는, Bugzilla는 여전히 구 Bugzilla에서 읽기 전용 모드로 이용 가능하다.wikimedia.org예를 들어, https://old-bugzilla.wikimedia.org/show_bug.cgi?id=16691은 효과가 있다.마트마 렉스톡스 17:29, 2015년 3월 5일 (UTC)

이는 다음 Phabricator 업데이트(T89690) 이후 수정될 것으로 알려진 사안이다.한편 https://phabricator.wikimedia.org/T18691?before=1 (주: about=1)은 과제에 대한 모든 의견을 보여준다. wctaiwan (대화) 21:46, 2015년 3월 5일 (UTC)

• WMF가 우리 모두가 싫어하거나 전혀 쓸모없다고 생각하는 것들을 실행한다는 것은 멋진 일이 아닌가...Diffs 말고는 여기 URL 비트는 사용할 필요가 없어서 개인적으로 볼 수 없지만 2인치 짜리 입니다. 어쨌든 감사합니다, 프라임님.코드 헌터 :) –Davey2010^Talk 16:33, 2015년 3월 6일 (UTC)

나도 요점을 모르겠어.이것은 기본적으로 목차까지 스크롤해야 하는 엄청난 번거로움을 덜어준다.산만함을 정당화할 수 있는 혜택은 거의 제공하지 않는다. --봉와리어(토크) 18:28, 2015년 3월 6일 (UTC)

봉와리어 - 맨 아래 페이지 또는 제목이 페이지 중간에 있는 영역인 경우 - 제목 옆에 있는 뱀 사물을 클릭하면 제목/부분이 화면 맨 위로 이동됨 ....그럼 그게 무슨 이득이..스크롤 막대를 사용하는 것이 좋을까? ....나는 솔직히 이것에 대해 아무 의미도 없다고 본다? –Davey2010^Talk 21:36, 2015년 3월 6일 (UTC)

내 잘못은 여기 있는 모든 걸 다 읽지는 않았어. 말이 되긴 하지만 개인적으로 난 몇 년 동안 TOC로 스크롤하는 걸 더 좋아해.–Davey2010^Talk 21:45, 2015년 3월 6일(UTC)

신용: 이것은 자원 개발자([40])에 의해 시행되었다.wctaiwan (대화) 22:16, 2015년 3월 6일 (UTC)

• 그래, 이건 정말 쓸모없는 기능이야. 하지만 사람들이 다른 것들을 원할 때 구현하는 데 몇 달이 걸리잖아.내 질문은 왜 아무도 변화의 작은 논의나 통고를 시작하기로 결정하지 않았는가 하는 것이다.여기 이 피비린내 나는 뱀들이 어디서 왔는지 알아내려고 내 도구들을 뒤지고 있었어!EoRdE6^{(Come Talk to Me!)} 19:47, 2015년 3월 6일(UTC)

그들은 실제로 위키미디어 사이트들의 많은 곳에 게시된 #Tech News:2015-10의 끝에서 그것을 언급했었다.당신은 당신의 토크 페이지인 메타에 테크뉴스를 전달하기 위해 가입할 수도 있다.글로벌 메시지 전달/대상/기술 홍보대사프라임헌터 (대화) 22:05, 2015년 3월 6일 (UTC)

이것은 2008년부터 특집 요청이 있어서 "월"보다 조금 더 오래 걸린 것 같아.Legoktm (대화) 22:10, 2015년 3월 6일 (UTC)

• 나는 우선 (사용성에 영향을 주지 않는 한) 긍정적인 변화라고 생각한다.기사/페이지 섹션에 링크를 복사하는 것이 멍청할 정도로 쉬워진다.*만약* 전 세계적으로 제거된다면, 개인적으로 추가할 CSS 또는 JS 코드가 있는가?— Huntster (t @c) 23:13, 2015년 3월 6일 (UTC)

  나도 동의해.섹션 링크 URL을 얻기 위해 페이지의 맨 위까지 스크롤해야 한다는 것은 꽤 짜증나는 일이었다(그리고 그것은 TOC가 있다고 가정하는 것이다).프로토프: {{u2w}}와 함께 사용하면 잘 포맷된 위키링크를 얻을 수 있다.— 2015년 3월 7일 투어 05:06, Stradivarius씨(UTC)

그것은 편리하다.뱀을 보고 싶어하지 않고 CSS를 편집하는 것이 편하지 않은 사람들도 있으니, Preferences에 확인란을 어딘가에 추가할 수 있을까?

나는 그것이 짜증나고 산만하다고 생각하지만, 그것이 URL이 아닌 위키링크를 준다면, 나는 그것의 용도를 알 수 있었다.한 구역에 연결할 때, 한 구역은 대부분 집에서 하고 있다 - 음, 이건...나는 선택권이 너무 과할 것이라고 생각한다. 그것은 머리글의 왼쪽에 있을 때 나타나도록 요청하고 오른쪽으로 멀리 가지 않았다.페리돈 (토크) 2015년 3월 7일 12시 30분 (UTC)

@페리돈:레벨 2 이상의 제목 요소를 마우스로 가리킬 때 발생한다.대부분의 브라우저는 머리글의 텍스트가 상당히 짧더라도 머리글 요소를 페이지의 전체 너비를 차지하는 것으로 간주한다.위키피디아에서 레벨 2 머리글에는 하단 가장자리를 따라 옅은 회색 테두리가 주어진다(레벨 1 머리글, 즉 페이지 제목). 이는 제목이 전체 너비임을 보여준다. --Redros64 (토크) 13:26, 2015년 3월 7일(UTC)