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

실수로 비워진 삭제 검토 보관 파일을 스팸 필터를 누른 상태로 복원

1년 전 사용자:Pldx1은 실수로 2007년 Deletion 리뷰 아카이브의 대부분을 삭제한 것으로 보이며, 이는 Category에서 페이지를 삭제하기 위한 캠페인의 일환이다.템플릿에 크기가 포함된 페이지.일부는 복원했지만 일부는 템플릿에 스팸 차단 사이트 링크가 있어 복원할 수 없는 경우도 있고, 1월은 블록이 여러 개 있는 반면 2월과 4월은 블록이 각각 하나씩 있는 경우도 있다.템플릿 오버플로 문제를 해결하기 위해 분할하고, 비활성 사이트 제거 요청을 넣었는데, 스팸 차단 템플릿을 다시 받을 수 있는 방법은 없을까?페이지를 새로 만들어야 하고, 1월을 차단하는 모든 페이지들이 리스트에 남아 있어야 하기 때문에, 그냥 차단 해제할 수는 없다.실버백넷 01:44, 2017년 5월 3일(UTC)

Pldx1은 페이지를 비우지도 않았고, 편집한 것도 사고도 아니었다.그는 단지 그 템플릿들을 논평했을 뿐이다.그것이 실제로 그 문제에 대응하는 적절한 방법인지는 모르겠지만, 그것도 큰 문제는 아니다.Pldx1한테 물어봤어?Sometguy1221 (대화) 02:06, 2017년 5월 3일 (UTC)

여러분.2016년 3월 13일 14시 8분 편집 요약에 다음과 같이 적었다.

페이지를 유지할 수 있는 최적의 사용자...페이지 소유자 또는 페이지를 만든 부트 소유자.소유주 대신 다른 사람이 그 일을 해야 할 때, 그 소유주는 그 결과에 만족하지 않을 때 간단히 되돌아가서 혼자 그 일을 할 수 있다.

1년 전, 나는 "위키 프로젝트 스팸"이 카테고리를 스팸으로 보낸 상황을 발견했다.템플릿에 크기가 포함된 페이지.나는 그 난장판을 치우기 위해 이 프로젝트의 누군가와 협력하여 노력했다.나는 문제가 재발하고 있는 것 같은 인상을 받는다.상황 고치는 행운을 빈다! Pldx1 (대화) 21:49, 2017년 5월 3일 (UTC)

한 페이지를 논평하는 것은 여전히 널리 "공백"이라고 불린다.어쨌든 나는 정말 문제가 어떻게, 왜 발생했는지는 상관하지 않고, 누구를 탓하는 것이 아니라, 문제를 해결해서 보관된 분쟁에 대한 편집이 스팸 필터에 의해 차단되는 동안, 그 문제를 해결하고 보관소를 다시 가져오는 데 더 신경을 쓴다.나는 그것에 접근하는 다른 방법이나 페이지 레벨의 수당을 받아야 하는지에 대한 조언을 구하고 있다.실버백넷 02:32, 2017년 5월 4일 (UTC)

사용자:Beetstra가 MediaWiki Talk에 다음과 같이 표시함:스팸-블랙리스트는 블랙리스트를 삭제하거나 해결하는 것보다 특정 페이지에서 잘못된 링크를 제거하는 것이 더 바람직하다.좋아, 사건 종결.실버백넷 05:13, 2017년 5월 4일(UTC)

그 페이지에는 블랙리스트에 올라 있는 링크가 많아 논의의 편의를 제공할 뿐이다.도메인/링크는 이후 블랙리스트에 올랐다.그 중 지금은 두 곳만이 '죽은' 사이트다.내게 있어, 더 나은 해결책은 그러한 논의에서 블랙리스트에 오른 모든 도메인과의 연결을 해제하는 것이다 - 그것들은 별로 도움이 되지 않는다(편집자들이 10년 된 링크를 따르기를 원하는 극소수의 경우를 제외하고, 그들은 URL을 복사하여 붙여넣어야 한다).(참고: 일반적으로 내용 네임스페이스의 링크는 제거되며, 이 링크는 더 이상 편집되지 않는 아카이브된 페이지에 있는 만큼 제거된다(어쨌든 다시 추가되지 않음).이따금씩 (우리 아카이브봇의 블랙리스트 히트에서 목격한 것처럼) 아카이브 문제가 발생하는데, 나는 이 문제를 같은 방식으로 해결하려고 노력한다. --Dirk Beetstra 07:46, 2017년 5월 4일 (UTC)

그건 그렇고, 그 롤백은 효과가 있을 것 같아.페이지를 '브레이킹'하는 것은 페이지 생성과 링크를 새로 추가해야 하기 때문에 문제가 될 것이다. --Dirk Beetstra 07:47, 2017년 5월 4일 (UTC)

사용자:Dirk Beetstra는 "문제가 있다...내가 해결하려고 노력하는 것"이라고 말했다.사용자:SilverbackNet은 다음과 같이 말한다: "나는 정말로 문제가 어떻게, 왜 발생했는지에 대해 신경쓰지 않는다... case closed."위키백과로 이동:위키프로젝트_스팸/참가자, Dirk Beetstra가 등록되어 있는 반면 SilverbackNet은 등록되어 있지 않은 것을 알 수 있다.위키프로젝트 스팸의 등록된 회원은 보통 사람보다 더 친근한 경향이 있다고 결론을 내릴 수 있을까?

그런데 카테고리에 대한 작업:템플릿의 크기가 문제를 초과하는 페이지는 샌프란시스코 행정부의 태스크 중 하나여야 하지만...Pldx1 (대화) 09:13, 2017년 5월 4일 (UTC)

템플릿의 크기를 초과하는 페이지에 대한 더 나은 해결책은 먼저 분할하는 것이라고 생각한다(아카이브 절반).그것이 불가능할 경우에는 (부분) 블랭킹이 옵션이다.전자는 논의된 주제와 온전한 연계를 남기므로 찾기 쉽다.분명히 백지화/합성화되면 없어진다. --Dirk Beetstra^{T C} 12:44, 2017년 5월 4일 (UTC)

SilverbackNet, 블랙리스트에 있는 링크를 복원해야 하는 확실한 이유가 있다면 관리자에게 문의하십시오.삭제 및 복원 기능이 작동한다는 것을 알았다. admin이 페이지 삭제, 관리자가 링크를 삭제하기 직전에 버전을 복원하고, admin(또는 다른 사용자)이 페이지 수정본을 편집하여 새 "현재" 버전을 만들고, admin은 삭제된 모든 수정본을 복원한다.그것은 고통이고, 작은 것에 대한 노력의 가치도 없지만, 어떤 상황에서는 그것만이 유일한 선택이다.Dirk가 언급했듯이, 롤백은 블랙리스트 링크들을 복원시킬 것이다. 예를 들어, 나는 여기서 그것을 사용해야 했다. 예를 들어, 대화 합의가 이미 합의된 블랙리스트 링크를 복구하는 것은 우리가 공식 웹사이트를 가질 수 있는 가장 가까운 것이었기 때문이다.나이튼드 (토크) 02:25, 2017년 5월 7일 (UTC)

PS, 나는 삭제와 복원이라는 변종만 사용해도 페이지 분할을 해줄 수 있을 것 같아.내가 전체 내용을 삭제하고 수정본을 한 개 복원하고 새 제목으로 옮기고 편집하면 다른 페이지에 내용이 나온다.이렇게 하면 나머지 내용을 복원할 수 있고(아직 이전 제목에 있음) 목록 전체를 두 부 복사하여 별도의 절반 목록으로 만들 수 있다.내가 시도했으면 좋겠다면 알려줘.나이튼드 (토크) 02:28, 2017년 5월 7일 (UTC)

편집으로 무엇을 계산해야 하는가?

현재 MediaWiki는 데이터베이스에 등록된 모든 사용자의 편집 횟수를 기록한다.이 편집 카운트는 사용자가 자동 확인되거나 확장 확인되는 시기를 파악하는 것과 같은 다양한 용도로 사용된다.User:와 같은 다양한 사용자 스크립트에서도 사용된다.스탠드/userinfo.js.현재 이 편집 카운트는 사용자가 다음 중 하나를 수행할 때마다 증가된다.

• MediaWiki 페이지 수정 또는 편집(이후 수정본 또는 페이지가 삭제된 경우에도)
• 플로우 보드에 게시물 작성 또는 편집

편집 카운트는 다음과 같이 증가하지 않는다.

• 새 제목으로 페이지 이동
• 페이지 이동 중에 리디렉션 자동 생성
• 페이지 보호 또는 보호 해제

MediaWiki 소프트웨어를 수정하여 이러한 작업 중 하나를 "편집"으로 간주해야 하는가?FWIW, XTools Edit Counter 페이지 이동 횟수 및 자동 리디렉션 생성 횟수가 "edits"로 집계되므로 편집 횟수가 MediaWiki와 일치하지 않는다.라이언 칼다리 (WMF) (토크) 22:15, 2017년 5월 2일 (UTC)

메, 편집카운트염을 억제해야 할 것 같아.나는 개인적으로 로그 액션을 편집 카운터와 별도로 제외하곤 한다.'모두 개인적인 의견이다조조 유메루스 (토크, 기여) 22:20, 2017년 5월 2일 (UTC)

Ryan Kaldari (WMF): 커뮤니티에 의해 생성된 많은 버그 보고서와 기능 요청이 있는데, 이 편집 카운트 질문이 그 중 하나와 관련된 것인가?

또한, 나는 위의 AFAIK, WP에서 "편집"이라는 단어를 "수정"으로 바꾸었다.NULLEDITs는 카운트 목적의 편집으로 간주되지 않는다.– Jonsey95 (대화) 23:14, 2017년 5월 2일 (UTC)

@Jonsey95:고쳐줘서 고마워관련 Phabricator 태스크는 T163966과 T163284이다.라이언 칼다리 (WMF) (토크) 00:26, 2017년 5월 5일 (UTC)

나는 스페셜에 나열된 모든 것을 생각한다:기여 및 특별:DeletedColutions는 위에 나열된 모든 항목과 페이지 가져오기/수입 편집을 포함하여 편집으로 계산되어야 한다. 기본적으로 편집은 2002년 9월로 거슬러 올라가는 편집 횟수에 의해 X!' 카운터, 이전 버전 및 위키피디아 사람들의 과거 목록에 의해 항상 계산된 방법이다.데이터베이스 편집 카운트 필드는 2006년 12월에 [거의 주저함(지금은 찾을 수 없지만, 그 전에 요청되어 플랫 아웃이 거절된 실이 있었을 것임)]으로 추가되었다.많은 MediaWiki 기능(예: 원래 감독 시스템, 계단식 보호, 페이지 삭제에 대한 5,000 편집 제한)과 마찬가지로, 긴급한 상황을 지원하기 위해 상당히 특별하게 추가되었다.내가 말하고자 하는 것은: 나는 이 분야의 현재 시행이 돌로 정해져서는 안 된다고 생각한다.

그러나 나는 내 역사 기록 기록 작업, 데이터베이스의 편집 횟수, 특별 편집 횟수를 세어 보고된 편집 횟수를 너무 많이 옮겼기 때문에 이해 상충이 있는 것 같다.기여금은 상당히 극적으로 다르다.「위이엘, 그것은 ‥‥‥‥‥‥‥‥‥‥‥‥‥ 그라함87 10:06, 2017년 5월 3일(UTC)」으로 얼마나 많은 편집을 했는지에 대한 간단한 질문에 대답해야 하는 것이 싫다.

나는 페이지를 이동하거나 보호하는 것이 "편집"이라고 생각하지 않는다.

그러나 자동으로 생성된 리디렉션은 (리디렉션이 생성될 때 등)일 것이다.만약 당신의 이름이 그 페이지에 내용(즉, #REDION 코드)을 넣은 사람으로 (Redirect) 페이지의 기록에 나타난다면, 그것은 아마도 "편집"으로 간주되어야 한다.WhatamIdoing (대화) 17:42, 2017년 5월 3일 (UTC)

나는 Graham의 말에 동의한다. 만약 당신이 Special을 통해 모든 라인을 정확하게 세는다면 편집 카운터가 주는 숫자는 당신이 얻은 숫자와 같을 것이다.기여금, 그리고 이미 그렇게 작동하고 있는 경우 DeletedConcurrations.서로 다른 두 개의 편집 횟수를 갖는 것은 혼란스럽다; 우리는 단지 하나의 공식 편집 횟수를 가져야 한다.그 숫자를 어떻게 확인했든 간에, "나는 123456개의 실시간 편집과 789개의 편집이 있다"고 말할 수 있어야 한다.나이튼드 (대화) 02:33, 2017년 5월 7일 (UTC)

페이지 보호를 결정하기 위한 API 쿼리

API를 통해 페이지의 편집/이동 보호를 결정해야 한다(예: 사무실, 전체, 세미, 보류 중인 변경 사항 등).

카테고리 멤버십을 통해 하는 것은 쉽지 않다.예를 들어, 최상위 수준의 "카테고리:위키피디아의 반보호 페이지 아래에는 "카테고리:위키백과_indefinite_semi-protected_pages" 및 기타 많은 변형.하위 범주를 찾기 위해 재귀할 때, 보호되지 않는 페이지가 포함된 하위 범주와 백과사전의 거의 모든 범주를 나열하는 더 깊은 하위 범주를 빠르게 발견하게 된다.

나는 이것을 페이지 단위로 하는 효율적인 방법을 찾을 수 없었다."Special:" 기능에서 보호된 페이지의 전체 목록을 다운로드할 수 있는가?그럴지도 모르지, 하지만 그건 빠른 작업으로는 과잉 살상이 될 것 같아.West.andrew.g (대화) 02:21, 2017년 4월 7일 (UTC)

mw:API:Info#inprop=보호.프라임헌터 (토크) 02:44, 2017년 4월 7일 (UTC)

네, API가 가장 좋은 경로일 겁니다.카테고리와 같은 카테고리의 구성원 자격:위키피디아 반보호 페이지는 반드시 해당 카테고리의 모든 페이지가 반보호되어 있거나, 모든 반보호 페이지가 해당 카테고리에 있음을 의미하지는 않는다.카테고리는 단지 다음과 같은 페이지의 템플리트를 반영하는 것이다.{{pp-semi}}. 예: 사용자:레드로스64/샌드박스12는 2017년 5월 7일 09:28(UTC)까지 반보호되나 '보호된 페이지' 고양이에는 들어 있지 않다. --Redros64 🌹 (토크) 09:30, 2017년 4월 7일(UTC)

글로벌 워치리스트

모든 위키미디어 프로젝트를 위한 글로벌 감시목록이 있는가? -- Pankaj Jain Capankajsmilyo (talk · 기여 · count) 08:36, 2017년 5월 7일 (UTC)

아니, 페이지 참조:T3492. --말야코 (대화) 10:20, 2017년 5월 7일 (UTC)

돌진하다

다음 중 올바른 대시란 무엇인가?

• 모라비아-실레시아 축구 리그
• 모라비아실레시아 주

마이오 T. (대화) 19:11, 2017년 5월 6일 (UTC)

그건 스타일 문제야. WP: 참조:모스다쉬. 그게 확실하지 않으면 WT:Manual of Style에 있는 사람들이 조언을 해줄 것이다.조누니크 (대화) 01:06, 2017년 5월 7일 (UTC)

조누니크, 고마워!이제 확실한 것은, 정확한 간판이 하이픈이라는 것이다. 하지만 모라비아-실레시아 축구 리그라는 페이지는 옮길 수 없다는 것이다. 그 이름의 페이지는 이미 존재한다.마이오 T. (대화) 11:00, 2017년 5월 7일 (UTC)

@Maio T.:WP에 문의해야 할 것 같다.RM. Johnuniq (대화) 11:10, 2017년 5월 7일 (UTC)

마지막 편집기 옆에 있는 단추

diff 페이지의 마지막 편집기 옆 버튼은 항상 눈에 보인다는 점에서 깨지곤 했지만, 어떤 페이지를 클릭하든 가장 최근의 편집기만을 보여주었을 뿐이다.이제는 수동으로 변경사항을 표시해도 변경사항이 이루어진 것이 분명하다.네이처리움(토크) 18:37, 2017년 4월 26일 (UTC)

@Natureium:나는 네가 어떤 특징을 참고하는지 모르겠어.예제 링크를 사용하여 더 자세히 설명하고 로그아웃할 경우 기능이 표시되는지 여부 및 해당 경우에 작동하는지 여부를 확인하십시오.프라임헌터 (대화)20:44, 2017년 4월 27일 (UTC)

감시 목록 페이지에 있는 경우 "diff" 또는 "view history" 페이지를 클릭하고 "선택한 수정본 비교"를 클릭하면 "이전 편집기" 아래에 있는 옵션 중 하나가 "다음에서 마지막 편집기"가 된다.이 버튼은 편집자가 연속해서 두 번 이상 편집한 모든 페이지에서 볼 수 있음에도 불구하고 가장 최근의 편집에서만 작동하곤 했다.이제 그것을 클릭하면 "(차이가 없다)"라고 적힌 페이지로 이동하게 된다.네이처리움 (토크) 21:17, 2017년 4월 27일 (UTC)

@Natureium:해당 기능이 보이지 않고 내가 요청한 세 가지 작업 중 하나도 수행하지 않았지만 검색 결과 User:DerHexer/Revisionjumper#기능: ← 다음부터 마지막 편집자, 사용자별 스크립트:더헥서Special:에서 revision jumper를 사용 가능으로 설정하셨습니다.기본 설정#mw-prefection-gadgets.MediaWiki:Gadget-revisionjumper.js는 de:에서 코드를 로드하는 것을 보여준다.MediaWiki:가젯-리비전점퍼.js.또 한 번 명확한 질문에 답하고, 사용자들이 다양한 상황에 따라 다른 것을 본다는 것을 깨닫는다.심술궂게 굴어서 미안하지만 로그아웃하면 보고된 기능이 보이지 않는다는 것은 도우미에게 중요한 정보야.프라임헌터 (토크) 22:12, 2017년 4월 27일 (UTC)

나도 같은 이유로 이곳에 왔다.소스 코드를 파악한 것 같은데, 이 문제를 해결하기 위한 다음 단계가 무엇인지 잘 모르겠어.그걸 도와줄 수 있는 사람이 여기 있을까? -- Irn (대화) 13:41, 2017년 4월 28일 (UTC)

나는 사용자 이름을 위키링크로 위의 스크립트 작성자 더헥서에게 통지했다.그는 오늘날 독일어 위키피디아에 적극적이고 편집하고 있다.de:MediaWiki:Gadget-revisionjumper.js는 독일 관리자에 의해서만 편집될 수 있지만 다른 관리자들은 대화 페이지에 게시할 수 있다.프라임헌터 (대화) 22:04, 2017년 4월 28일 (UTC)

@Natureium, Irn, Prime내가 코드를 고쳤어나는 모든 것이 다시 돌아가고 있기를 바란다.베스트, —DerHexer(Talk) 23:32, 2017년 5월 1일(UTC)

@DerHexer: 아직도 나한테는 효과가 없어.리셋해야 할 게 있어?네이처리움 (토크) 13:57, 2017년 5월 2일 (UTC)

아직도 나한테는 안 먹히네.위키다타(그리고 거기 있는 다음에서 마지막 편집자 버튼과 같은 문제를 가지고 있다)에 대한 기술적인 문제도 몇 가지 부딪히고 있는데, 그 문제들이 관련이 없을까?또한, 나는 파이어폭스와 크롬 둘 다와 문제가 있다. -- Irn (대화) 00:53, 2017년 5월 3일 (UTC)

우프스, 난 마지막 편집만 고쳤어, 페놀트리메디터가 아니라곧 보고 언제 고쳐질지 알려줄게.베스트, —DerHexer (Talk) 23:24, 2017년 5월 3일 (UTC)

@Natureium, Irn, Prime헌터: 다시 시도하십시오.둘 다 지금 나를 위해 독일어 위키백과뿐만 아니라 영어 위키백과에서도 일했다.위키다타에 대한 단서는 없어.베스트, —DerHexer(Talk) 00:06, 2017년 5월 4일(UTC)

해냈다!정말 고마워! -- Irn (대화) 02:07, 2017년 5월 4일 (UTC)

가장 최근 편집에서 '마지막 편집자 옆'을 클릭했을 때는 효과가 있었지만, 이전 편집으로 돌아가면 다시 "(차이가 없다)"는 것을 보여줬다.가장 최근 편집한 것을 다시 한 번 시도했더니 (차이가 없다)는 것도 나오고 있다.네이처리움 (토크) 14:05, 2017년 5월 4일 (UTC)

그래, 80% 정도는 나한테 효과가 있어효과가 없을 때 특별히 다른 것이 있는지 알 수 없는 것 같다.몇 년 동안 그랬던 것처럼 100% 작동하지 않는 것이 조금 답답하긴 하지만, 대부분의 시간 동안 작동하는 어떤 편집 도구는 내 생각으로는 대성공이라 불평하지 않는다. :) -- Irn (대화) 13:40, 2017년 5월 7일 (UTC)

모빌 범주

왜 고양이는 모바일에 보이지 않는가? -- Pankaj Jain Capankajsmilyo (토크 · 기여 · 카운트) 12:21, 2017년 5월 7일 (UTC)

모바일은 화면 공간을 다 쓰지 않는 것 외에는 쉽게 눈에 띄는 이유 없이 유용한 정보를 1hekuvalot 숨겨주기 때문이다. --Redrose64 🌹 (토크) 13:49, 2017년 5월 7일 (UTC)

가능하겠는가? -- Pankaj Jain Capankajsmilyo (토크 · 기여 · 카운트) 14:02, 2017년 5월 7일 (UTC)

그래. 하지만 만약 당신이 그 반대를 뚫고 싸울 수 있다면: 그것은 우리가 통제할 수 없는 MediaWiki 소프트웨어 변경이 필요하기 때문에. --Redrose64 🌹 (토크) 15:32, 2017년 5월 7일 (UTC)

아니, 오히려 이 많은 일을 통해.조조 유메루스 (토크, 기여) 15:38, 2017년 5월 7일 (UTC)

템플릿:인포박스 정산 문제

안녕. 나는 XAMPP에 Mediawiki 1.28.2를 설치했어. 나는 이 템플릿을 만들었어.그러나 내가 사용하려고 할 때 문제가 있다는 것을 알게 된다.settlement_type parametr을 사용하면 추가가 발생함

</th>[th]

부호를 붙이다

예 1(문제 없음):

{{인포박스 정착 공식_name=이스탄불 native_name="İstanbul" native_name_lang=tr image_skyline="native_name"이스탄불 콜라주 5j.jpg imagesize=270px image_alt=자막 image_caption=시계방향:View of the [[Golden Horn]] between [[Karaköy]] and [[Sarayburnu]] within the [[Historic Areas of Istanbul historic areas]]; [[Maiden's Tower]]; a [[Istanbul nostalgic tramways nostalgic tram]] on [[İstiklal Avenue]]; [[Levent]] business district with [[Dolmabahçe Palace]]; [[Ortaköy Mosque]] in front of the [[Bosphorus Bridge]]; and [[Hagia Sophia]] }}}

: 예 2 (문법 포함):

]] ={인포괄호_이름=이름='Easternstanbul's native_name_lang=tr settlement_type=[[터키로로자리리자자자자자자자자자]]]]]]]] image_skyline=]이스탄불 콜라주 5j.jpg imagesize=270px image_alt=자막 image_caption=시계방향:View of the [[Golden Horn]] between [[Karaköy]] and [[Sarayburnu]] within the [[Historic Areas of Istanbul historic areas]]; [[Maiden's Tower]]; a [[Istanbul nostalgic tramways nostalgic tram]] on [[İstiklal Avenue]]; [[Levent]] business district with [[Dolmabahçe Palace]]; [[Ortaköy Mosque] [보스포루스 다리] 앞, [하자 소피아][Haja Sophiaa] }}

어떻게 하면 고칠 수 있을까? --Drabdullayev17 (대화) 06:37, 2017년 5월 7일 (UTC)

@Drabdullayev17: 이 문제가 나타나는 예제 페이지로 링크하십시오. --Redrose64 🌹 (대화) 08:32, 2017년 5월 7일 (UTC)

@Redros64: 내 로컬 호스트에 Mediawiki를 설치하기 때문에 연결할 수 없다.그러나 오래된 템플릿을 사용하면 문제가 없다. --Drabdullayev17 (대화) 08:51, 2017년 5월 7일 (UTC)

템플릿 토크에 게시함:Infobox 정산#settlement_type 문제.차이점은 우리가 HTMLTidy를 사용한다는 것일 수도 있다.프라임헌터 (토크) 10:07, 2017년 5월 7일 (UTC)

...잠깐만 더 있다.만약 이 문제가 정말로 (의 부재) 때문이라면깔끔하게, 그럼 이것만이 그 영향을 받는 Infobox 템플릿이었으면 좋겠어.Whatamidoing (WMF) (토크) 05:48, 2017년 5월 8일 (UTC)

첫 번째 단계로 enwiki에서 예제 2를 다른 Wikitext가 없는 샌드박스에 붙여 넣은 다음 결과를 미리 보십시오.맨 아래에서 "이 미리 보기에 사용된 템플릿"을 검토하십시오.표시된 템플릿과 모듈이 있는지 확인하고 복사본이 여기에 표시된 것과 정확히 일치하는지 확인하십시오.즉, 최신 수정 사항이 있는지 확인하십시오.enwiki에서 예제 2를 사용하면 결과에서 "th"가 두 번 나타난다.3개 가지고 있다는 거야?조누니크 (대화) 10:26, 2017년 5월 7일 (UTC)

@Johnuniq: 템플릿 토크에서 내 게시물을 보십시오.Infobox 정산#settlement_type 문제.프라임헌터 (대화) 10:35, 2017년 5월 7일 (UTC)

고마워, 방금 예쁜 html 덤프 올려놨는데 맞는 것 같아.나는 더 이상의 토론은 다른 페이지에 있어야 한다고 생각한다.조누니크 (대화) 11시 13분, 2017년 5월 7일 (UTC)

en.m.의 좌표.wikipedia.org

모바일 디스플레이가 데스크톱과 같은 모든 상황에서 조정되지 않는 이유는?오늘 이곳을 방문할 때 분화구 전투의 위치를 찾고 싶어서 기사를 실었는데 놀랍게도 눈에 보이는 조율이 없었다.https://en.wikipedia.org/wiki/Battle_of_the_Crater은 ( 마치 그들이 다 한 것처럼) 위에 좌표를 가지고 있다. display=inlinehttps://en.m.wikipedia.org/wiki/Battle_of_the_Crater에는 좌표가 없다.나이튼드 (토크) 02:12, 2017년 5월 7일 (UTC)

현황은 알 수 없지만 2013년 8월 자료실에서 이 문제가 논의됐다.

기사(분화구 전투)는 아래쪽에 다음과 같은 내용을 담고 있다.

{{coord 37.2183 -77.3777 region:US_type:event display=title}}

조누니크 (대화) 02:25, 2017년 5월 7일 (UTC)

모바일은 좌표를 보여주지 않는다. 단지 아무도 모바일 페이지 안에서 그 좌표를 나타낼 수 있는 좋은 지점을 찾지 못했기 때문이다(내 모바일 벡터 피부조차도 좌표를 완전히 숨긴다).따라서 이 페이지와 같이 오른쪽 상단에 좌표만 표시되고 다른 곳에 인라인으로 표시하지 않으면 좌표는 표현되지 않는다.나는 개인적으로 당신이 처음부터 단순히 표시만 있는 좌표를 가져서는 안 된다고 생각하지만, 우리가 지금 atm에 있는 상황은 아니다.어쨌든.phab에 추적 티켓이 있다.T91481, 그리고 만약 새로운 디자인 아이디어를 가진 사람이 있다면, 그들은 그곳에서 매우 환영받을 것이다.—DJ (대화 • 기여) 08:44, 2017년 5월 8일 (UTC)

소스 편집기 하드 래핑?

지난 1, 2주 동안 나는 위키 소스 코드 편집기의 너무 긴 텍스트 줄이 하드포장되어 공간을 뉴라인+스페이스로 바꾸는 간헐적인 문제를 겪고 있었는데, 이것은 줄의 그 지점 이후 무엇이든지 들여쓰기된 텍스트 블록으로 변하게 한다.차이가 있다면 MacOS X(10.12.4)와 Chrome(58.0.3029.81)에서 확인할 수 있다.다른 사람이 이걸 본 적이 있는 거야? 아니면 나만 본 거야?— David Eppstein(대화 • 기여) 00:28, 2017년 5월 7일 (UTC)

@David Eppstein:사용자 스크립트처럼 들리거나 심지어 브라우저 확장이 간헐적으로 이러한 변화를 만들고 있다.그것들을 치우고, 하나씩 활성화함으로써 범위를 좁히도록 노력하라. (단순히 로그를 보관하라, 간헐적인 성질 때문에, 어느 시점에서 두세 걸음 뒤로 돌아가야 할 수도 있다.)—DJ (대화 • 기여) 08:48, 2017년 5월 8일 (UTC)

{{Rfd}} 사용

리디렉션에 대해 논의할 때 템플릿:Rfd는 템플릿별로 대체됨:Rfd/doc.이 작업을 수행하면 {{Rfd}}을(를) 사용하는 동안 리디렉션이 의도적으로 깨진다.그게 우리가 할 수 있는 최선이야?봇이 논의되고 있는 리디렉션을 사용할 때 사용자에게 대화 페이지에 메시지를 보내는 것이 가능할까?할 만한 가치가 있을까?생각해줘서 고마워.-존 클라인 (대화) 00:47, 2017년 5월 8일 (UTC)

기술적으로 가능하다고 해도 이것이 승인될 방법은 절대 없다. 당신이 방문한 페이지를 공개 로깅하는 봇의 의미에 대한 프라이버시 함축은 법률적이고 윤리적 악몽이 될 것이다. (구체적인 예로서, 동물 포르노물은 현재 리디렉션된 것이다.)만약 내가 동물원필리아보다는 포르노를 지향하는 것이 더 낫다고 판단하여 RFD로 가져가 토론에 참여하는 사람들을 포함한 그 리디렉션에 방문하는 모든 사람들에게 "최근 동물 포르노를 검색했다"는 공지로 그들의 토크 페이지를 장식하게 될 것이다.특히 실명으로 편집하여 자신의 이름의 상위 검색 결과로 자신의 대화 페이지를 가지고 있는 사람들에게 이것은 다소 바람직하지 않을 수 있다.)Echo 시스템을 사용하여 알림 탭에 ping을 추가하더라도 WMF가 개인 정보 보호에 심각한 영향을 미치는 특정 편집자가 방문한 페이지의 로그를 보관하는 것을 의미하기 때문에 문제가 될 수 있다.∙ 무지개빛 08:58, 2017년 5월 8일 (UTC)

@Iriidescent: 이것은 정말로 나쁜 생각이라는 것에 동의했지만, 사용자들의 대화 페이지는 이미 색인화되지 않았다.Graham87 09:14, 2017년 5월 8일 (UTC)

@Graham, 그건 상징적인 제스처야. 엔위키에 있는 어떤 것도 노인덱스 속성을 존중하지 않는 사이트에 의해 미러링되기 때문에.구글에 "Greenapple220이 자신의 토크 페이지에 게시된 것이 매우 이상하다"는 문구를 입력하면 바로 해당 토크 페이지가 뜬다.- 이리슨트 09:25, 2017년 5월 8일(UTC)

나도 이리데센트의 추리에 동의해.지금 우리가 가지고 있는 것이 그만큼 좋은 것인가?--존 클라인 (대화) 09:53, 2017년 5월 8일 (UTC)

직립

이미지를 삽입하기 위해 "올바른" 옵션을 전체적으로 추가할 가능성이 있는가?나는 그 기능이 거의 사용되지 않기 때문에 실제로 유용할 수 있다고 생각한다.미리 코멘트해줘서 고마워 best--hubon (토크) 20:51, 2017년 5월 5일 (UTC)

"광택적으로 추가"라니 무슨 뜻이야?내가 아는 바로는upright위키백과의 옵션:확장 이미지 구문#규모는 모든 Wikimedia Wiki에서 작동한다.일부 편집 도구에 옵션을 추가하는 것인가?프라임헌터 (대화) 21:20, 2017년 5월 5일 (UTC)

@PrimeHunter:게시해줘서 고마워!그리고, 네, 사실 일반 편집 표면을 말하는 겁니다. 이미 "임베디드 파일" 옵션을 찾으셨을 겁니다."광대하게"함으로써 나는 이 개선이 모든 위키에 대해 구현되어야 한다는 것을 암시하고 싶었다.Best--Hubon (대화) 21:55, 2017년 5월 5일 (UTC)

편집에는 몇 가지 방법이 있다.위키백과를 말하는 것 같은데:특수에서 "편집 도구 모음 표시(JavaScript 필요)", "향상된 편집 도구 모음 사용" 및 "링크, 서식, 테이블, 인용문 및 검색 및 교체 기능에 대한 마법사 사용"이 모두 사용 가능한 경우 데스크톱 소스 편집을 위한 RefToolbar/2.0:기본 설정#mw-사전 섹션 편집프라임헌터 (대화) 22:48, 2017년 5월 5일 (UTC)

@PrimeHunter:편집 버튼을 클릭하여 여는 표면을 말하는 거야...도구 모음에서 "추가 링크 버튼"의 오른쪽에 있는 아이콘을 "임베디드 파일"이라고 한다.이 아이콘을 클릭하면 이미 다른 선형 및 형식에서 선택할 수 있지만, "상위"는 여전히 누락되어 있다.그리고 그게 바로 내 다공증 때문이지.인사말--후본 (대화) 08:17, 2017년 5월 6일 (UTC)

불행히도, 장치/프리프/등에 따라 "편집 버튼을 클릭하여 여는 표면만 간단히" 되는 것이 12개 정도 있다.mw를 확인하십시오.편집자, 스크린샷 중 사용 중인 스크린샷이 있는지 확인하십시오.(2010년에 도입되어 옅은 청색의 도구모음을 가지고 있는 「위키에디터」는 아마도 이 위키에서 가장 일반적으로 사용되는 것 같다.)Whatamidoing (WMF) (토크) 05:42, 2017년 5월 8일 (UTC)

@Whatamidoing (WMF): 게시해줘서 고마워.그래, 내 말은 "정규적인" 2010 벡터 편집기 말이야.Best--Hubon (대화) 12:02, 2017년 5월 8일 (UTC)

FB효과군

안녕, 페이스북에 있는 사람들을 위해, 나는 아이디어를 공유하기 위해 Effectivity (Wikimedia) 그룹을 설립했다. 어떻게 하면 기술적 도구와 방법론적 방법으로 위키미디어 프로젝트에 기여하는 것을 쉽게 할 수 있을까.---Juandev (대화) 2017년 5월 8일 (UTC)

무엇 때문에?우리는 위키백과의 문제를 토론한다.사람들이 위키백과의 문제를 오프위키(Off-wiki)에서 논의하기 시작하자 마자, 인-크라운("우리는 당신을 모르기 때문에 여기에 게시하지 않을 것이다"), WP:OWERship("이러한 변화는 페이스북 포럼에서 합의되지 않았으므로 되돌려야 한다"), 악감정과 거절. --Redrose64 🌹 (토크) 11:14, 2017년 5월 8일 (UTC)

그래, 공동체를 훼손하는 모든 것들 중에서 말이 안 통하네— O Fortuna ^{semper crescis, aut decrescis} 11:26, 2017년 5월 8일 (UTC)

아마도 이런 노력은 여러분이 경고하고 있는 것처럼 이미 여러 가지 방식으로 작용하고 있는 공동체에 대한 대응일 수도 있다는 것을 고려해야 할 것이다.만약 사람들이 '외부 장소'를 찾고 있다면, 우리는 '내부 장소'에서 그들을 놓치고 있는 것 같다.개인적으로, 나는 왜 페이스북이 IRC, IRL 스탬티슈 미팅 또는 OTRS보다 더 나쁜지 모르겠다 —TheDJ (대화 • 기여) 2017년 5월 12일, 8일 (UTC)

베타 기능 2열 편집 충돌 보기

비르기트 뮐러(WMDE) 14:28, 2017년 5월 8일(UTC)

x-tools 문제에 대한 질문

안녕, 그냥 x-tools에 대해 간단히 물어볼게 있어.실제로 수 천 개의 편집이 있고 (일부 경우) 관리자인 경우, 일부 계정은 편집이 0인 것으로 표시되고 몇 초 만에 로드되는 이유는 무엇인가?이것의 예는 여기에서 찾을 수 있다.시간 내주셔서 감사합니다 --The Sand Doctor (토크) 19:50, 2017년 5월 8일 (UTC)

업데이트: 이제 해당 링크에서 통계가 로드되고, 이상해.하지만 이 문제를 처음 접하게 된 것은 아니다. --The Sand Doctor (대화) 19:50, 2017년 5월 8일 (UTC)

테크 뉴스: 2017-19

02:25, 2017년 5월 9일 (UTC)

"경고"를 얻는 것은 다른 편집자들을 위한 것이었다.

나는 많은 불만 해결과 비슷한 지노밍을 한다.이따금씩 나쁜 링크를 고친 후 스팸을 추가하거나 잘못된 장르를 추가하는 내용의 메시지와 함께 편집이 되돌렸다는 '경고'를 받게 된다.사실, 이 메시지는 내가 방금 링크 수정을 한 편집자 중 하나를 위해 만든 이전 편집자를 위한 것이고, 그 추가 또한 되돌렸다.실제로 불쾌감을 주는 편집을 한 편집자도 이런 경고를 보는지 모르겠지만, 나는 분명히 볼 필요가 없다.bd2412 T 02:26, 2017년 5월 9일 (UTC)

이 경고들은 어떻게 도착하고 있는가?토크 페이지에서?페이지 상단에 있는 알림(종 및 받은 편지함 아이콘)에서?– Jonsey95 (대화) 03:05, 2017년 5월 9일 (UTC)

또한 당신이 이 일이 일어난 곳에서 편집한 한 두 페이지를 언급할 수 있다면 그것은 무슨 일이 일어나고 있는지 추적하는데 도움이 될 것이다.마넷DTalk 03:08, 2017년 5월 9일 (UTC)

벨-아이콘 알림장이다.예를 들어, 이것, 이것, 이것. bd2412T 04:22, 2017년 5월 9일 (UTC)

기술적으로, 두 편집 모두 되돌렸다.경우에 따라 2명의 편집자가 동일한 페이지의 다른 부분을 편집한 다음 누군가가 이전 버전을 복원하는 경우, 두 편집자에게 통지해야 하며, 두 번째 편집자에게 통지할 필요가 없을 때 소프트웨어도 알 수 없다는 점을 명심하십시오.עודדוו Od Mishehu 05:02, 2017년 5월 9일 (UTC)

(충돌 편집)나도 알아.그것은 완전히 정상이고, 당신이 잘못한 것이 없다는 것을 의미하지 않는다.현재 일어나고 있는 일은 다음과 같다.

1. 누군가가 편집을 하거나 여러 사람이 일련의 편집을 한다.
2. 후속 편집을 한다.
3. 다른 누군가가 당신의 글을 포함한 편집된 모든 시리즈를 이전 버전의 기사로 되돌릴 필요가 있다고 결정하고, 그것을 되돌린다.
4. 사용자를 포함하여 원래 편집 체인에 있었던 모든 사용자는 알림을 받는다(알림 기능이 켜져 있는 경우).

예를 들어 캡틴 아메리카의 방패에서는 누군가가 (알려진) 카피비오 뭉치를 추가했고, 당신이 그것을 정리했고, 그리고 나서 두 편집이 모두 뒤바뀌었다.내게 이런 일이 일어날 때, 그것은 전형적으로 내가 한 페이지에 대한 하나 이상의 바람직하지 않은 편집에서 이루어진 사소한 오류를 정리했기 때문이다.내가 원하지 않는 편집을 정리하고 있었으므로, 내 편집을 되돌려야 한다.내가 고치고 있던 오류가 여전히 사라진 이상, 나는 이 일련의 사건들에 대해 아무런 문제가 없다.페이지 기록과 요약 편집을 확인하면 대개 모든 것이 정상인지, 다른 것을 수정해야 하는지 확인하게 된다.– Jonsey95 (대화) 05:03, 2017년 5월 9일 (UTC)

디프 디스플레이가 왜 그래?

안녕, 디프 디스플레이에 무슨 일 있어?Honeyguide에서 다음 차이점

https://en.wikipedia.org/w/index.php?title=Honeyguide&curid=255432&diff=779422017&oldid=772944792

기본적으로 완전히 실패한다.오랫동안 특별히 잘 작동하지는 않았지만, 만약 이것이 잘 작동한다면, 그것은 중요한 도구고, 그 순간에는 쓸모없는 것이 아니기 때문에 정말로 고쳐야 할 필요가 있다.Chiswick Chap (대화) 20:47, 2017년 5월 8일 (UTC)

정말 최근에 뭔가 변한 것 같다.넷 디프가 보이도록 IP가 제거한 뉴라인을 추가했다.나는 이것을 페이브리카토르에 보고할 수 있다.니르모스 (대화) 21:02, 2017년 5월 8일 (UTC)

이것은 이제 팸플릿이다.T164795, 그러니까 미디어위키 개발자들이 그것에 대해 뭐라고 말하는지 좀 더 지켜봐야겠습니다.니르모스 (대화) 21:08, 2017년 5월 8일 (UTC)

나는 WP를 유지한다.이 문제를 위해 설치된 WikEdDiff. --Izno (대화) 22:34, 2017년 5월 8일 (UTC)

이게 정말 새로운 행동인가?단락을 삽입, 제거 또는 이동했을 때, 디프 엔진이 잘못 추측하여 잘못된 단락과 일치시키려고 할 때, 불량 디프트를 얻는 것은 오래된 문제다.빈 행은 단락처럼 취급할 수 있다.여기서 빈 줄이 제거되었지만 디프는 새 개정판의 다음 빈 라인과 이전 빈 라인과 일치했다.2006년의 phab:7072는 "문단이 분열되고 분산되지 않은 이동"이다.프라임헌터 (대화) 23:19, 2017년 5월 8일 (UTC)

그것은 새로운 행동이 아니다. 이것은 적어도 8년 동안 문제가 되어왔다.빈 줄을 제거하거나 추가할 때, 같은 편집에서 빈 줄을 따르는 문단을 변경하면 디프 엔진이 동기화되지 않는다. --Redrose64 🌹 (토크) 23:36, 2017년 5월 8일 (UTC)

나는 모든 사람들이 디프 엔진이 빈 선과 같은 사소한 변화에 대처할 수 있기를 원한다고 생각한다.Chiswick Chap (대화) 05:59, 2017년 5월 9일 (UTC)

"Merge" 탭 및 압축 언어 링크

몇 달 전, 나는 다음과 같은 코드로 (모노북에서) "merge" 탭을 설정했다.

+ sp:mw?title=sp:mw.config.get('wgScriptPath') + '/index.php?title=Sp:+ 인코드MergeHistory&target=' + 인데임브리지 'wgReallyPageName'), 'Merge';

나중에 내가 더 이상 이 탭을 많이 사용하지 않을 때, 나는 "Compact 언어 링크"라는 베타 기능을 추가했다.좀 더 최근에 나는 "merge" 탭이 사라졌고, "Compact 언어 링크"를 비활성화해야만 다시 가져올 수 있다는 것을 알아차렸다.누군가가 그 문제에 대해 더 나은 해결책을 생각해 낼 수 있을까?עודדוו ויו ו mis od od od 미셰후 04:37, 2017년 5월 9일 (UTC)

@Od Mishehu:이제 더 나아졌나?—DJ (대화 • 기여) 06:57, 2017년 5월 9일 (UTC)

응, 고마워.עודדווו Od Mishehu 11:25, 2017년 5월 9일 (UTC)

기부 이력의 중복 출품.

이건 내가 원래 올렸던 헬프데스크에서 만든 C&P 입니다.버그로 간주될지는 모르겠지만, 먼저 여기로 가져와봐.

나는 방금 내가 편집한 많은 부분이 내 기부자 목록에 두 번 나타나는 것을 알아챘다.매우 구체적인 컷오프인 것 같다. 2015년 9월 4일 2027h에서 한 번만 편집했는데, 그 다음 편집은 9월 4일에 두 번 나온다. 그리고 이것은 2016년 8월 23일까지 계속된다.

기사 기록에는 단 한 번만 나타나는데 데이터 검색에 오류가 있는 것 같아?Chaheel Riens (대화) 13:39, 2017년 5월 8일 (UTC)

와, 이상하네!이 스패닝 날짜를 쉽게 볼 수 있어 중지됨.--Fuhgettaboutit (대화) 22:17, 2017년 5월 8일(UTC)

나는 "오 예 - 알려진 문제" 등의 선에 따라 반응을 얻을 것으로 기대했지만, 유일한 반응은 푸그제트 관련이트로부터 나왔고, 그것은 그것이 이전에 보여지지 않았다는 것을 암시한다.Chaheel Riens (대화) 07:46, 2017년 5월 9일 (UTC)

오래된 ORES 중복 행이 아직 정리되지 않은 것 같아.phab:T164530은 문제를 완전히 해결하기 위한 과제인 것 같다.Anomie⚔ 12:55, 2017년 5월 9일 (UTC)

API를 통한 Null 편집

API를 통한 편집 처리 방법이 변경되었는가?오래된 템플릿 전폐가 있는 페이지(예: 다음을 포함하는 카테고리 페이지)가 있다고 가정{{Category redirect}}-- 카테고리에 내용이 있는 경우, 템플리트는 자동으로 페이지를 카테고리:위키피디아 비비어 소프트 리디렉션 카테고리 - 그러나 내용을 재분류할 경우, 페이지를 다시 편집하거나 강제 재커서링크 업데이트를 수행할 때까지 템플리트가 업데이트되지 않는다.웹 인터페이스를 통해 이 페이지에서 null 편집을 수행하면 템플릿 업데이트와 적용 불가능한 범주가 제거되지만 API를 통해 null 편집을 수행하면 아무 일도 일어나지 않는다.적어도 상당히 최근까지 API를 통한 null 편집과 웹 인터페이스를 통한 null 편집도 같은 방식으로 작동했다. --R'n'B (Call me Russ) 2017년 5월 9일 (UTC)

TH 버튼 가젯 문의

안녕, 기술 도우미들.나는 찻집에서 헤더 템플릿을 청소하려고 하다가, 그 변화로 인해 "질문해" 장치가 작동하지 않는다는 것을 알게 되었다.나는 가젯 기능을 바꾸었을 예전 혹은 새로운 템플릿에서 어떤 것도 볼 수 없었다.조언 좀 해주시겠습니까?Gtstricky^{Talk or C} 14:58, 2017년 5월 9일 (UTC)

당신은 중요한 구조 변경을 했고, 그래서 그 장치가 작동을 멈출 수도 있었다.러슬릭_제로 16:40, 2017년 5월 9일 (UTC)

DJ랑 스트라디바리우스 씨한테 제안할 거 있어?너희들은 이 코드를 잘 알고 있는 것 같구나.Gtstricky^{Talk or C} 20:59, 2017년 5월 9일 (UTC)

내가 어떤 새로운 기사를 만들었을까?

이 페이지는 내가 얼마나 많은 새로운 기사를 만들었는지를 말해주려고 한다.어떻게 그런 정보를 입수할 수 있었는지는 밝히지 않고 있다.내가 만든 새로운 기사 목록을 찾을 방법이 있을까?마이클 하디 (대화) 05:37, 2017년 5월 9일 (UTC)

enwiki, Special:기여/마이클 하디에는 맨 아래에 "Articles created" 링크가 포함되어 있다.그것은 정보를 조회하는 wmflabs 도구에 연결된다.페이지가 많으면 실행하는데 몇 분 정도 걸릴 수 있다.조누니크 (대화) 05:56, 2017년 5월 9일 (UTC)

대부분의 위키에서는 네임스페이스=(제목) 및 페이지만 작성과 같은 기여 필터도 사용할 수 있다.— Xaosflux 13:52, 2017년 5월 9일(UTC)

고마워, @Johnuniq: 그리고 @Xaosflux:마이클 하디 (대화) 00:41, 2017년 5월 10일 (UTC)

감시 목록에 있는 기사가 변경될 때 전자 메일 알림을 받지 못하는 중

이것은 지난 1년 동안 산발적으로 일어나고 있다기사가 너무 많이 나올까 봐 워치리스트를 다듬었는데도 올해는 빈도가 더 높아졌다.가장 최근의 예: 내 워치리스트에 있는 한 기사는 (내가 편집에 매우 적극적으로 참여했던) "4월 21일"에 한 편집자에 의해, 그리고 4월 25일에 GreenC bot에 의해 3번 편집되었지만, 나는 그것에 대한 이메일을 받지 못했다.오늘(2017년 4월 29일) 기사를 찾아가 그 역사를 살펴봤기 때문에 편집된 내용만 발견했을 뿐이다.나는 내 감시 목록을 다시 확인했고, 그렇다, 그 기사는 거기에 포함되어 있다.

나는 워치리스트 설정을 확인했어.다음과 같이 적혀 있다.

당신은 당신의 감시 목록에 51페이지가 있다(토크 페이지 제외).

이메일 알림이 활성화되어 있다.

> 에서는 Preferences > Advanced options 에서 다음과

• 최근 변경 사항뿐만 아니라 모든 변경 사항을 표시하도록 감시 목록 확장
• 감시 목록에서 편집한 내용 숨기기
• 내가 만든 페이지와 내 감시 목록에 업로드하는 파일
• 내 감시 목록에 업로드하는 새 파일 추가
• 에집 집시

선택사항에는 이메일 알림을 받을 수 없는 항목이 없음.Pixis Lonely (대화) 09:56, 2017년 4월 29일 (UTC)

알림이 "스팸" 폴더에 저장되었는지 확인하셨습니까?Anomie⚔ 15:32, 2017년 4월 29일 (UTC)

응. 나는 gmail을 사용하고 스팸 폴더에 어떤 것이 있으면 폴더 이름이 굵게 표시돼.너의 답장을 읽고 확인해보니 비어있어.최근 6개월 동안 워치리스트 e-메일 알림을 받은 경험은 (1) 기사가 바뀐 지 2, 3일 만에 받는 경험이나 (2) e-메일을 전혀 받지 못하는 경험이다.내가 참조한 기사의 편집 3건이나 봇 편집에 관한 이메일을 아직 못 받았어.어딘가에 벌레가 있다.Pixis 단독 (대화) 09:25, 2017년 4월 30일 (UTC)

변경에 대한 이메일을 받은 후 각 기사를 방문하시겠습니까?그렇지 않으면, 방문하기 전까지 그 기사에 대한 더 이상의 이메일을 받지 못할 것이다.Graham87 12:26, 2017년 4월 30일 (UTC)

만약 기사의 변경에 대한 이메일을 받지 못한다면 -- (그것은, 내가 받아야 할 모든 이메일을 받는 데 문제가 있다는 것이 나의 기술적인 문제라는 것이다.) 그러면 나는 특정 기사의 변경에 대해 알지 못할 것이다.하지만 기사에 대한 이메일을 받으면...나는 변화를 보기 위해 그 기사를 방문한다.나는 51페이지의 내 감시 목록을 가지고 있다.이메일 통지는 51개 모두에 대해 활성화되어 있다.그런 일은 일어나지 않는다. 왜냐하면 내가 나의 감시 목록을 볼 때 나는 51개의 기사들 중 많은 것에 변화가 생겼다는 것을 알기 때문이다.이메일 알림 설정에 영향을 주는 버그가 있는데, 문제를 일으키는 것은 위키피디아 입니다.Pixis 단독 (대화) 06:55, 2017년 5월 3일 (UTC)

위키에서 온 이메일에 다른 문제가 있으십니까?예를 들어, 누군가 Special을 사용하는 경우:노트를 보낼 EmailUser, 빠르고 안정적으로 작동하시겠습니까?Whatamidoing (WMF) (토크) 17:21, 2017년 5월 3일 (UTC)

지금까지 나는 다른 위키피디아인들로부터 이메일을 받는 데 아무런 문제가 없었다.그러고 보니...누가 이메일을 보냈는데 못 받았는지 어떻게 알아? (내가 무시했다고 생각하는 사람이 있다면?젠장.) 팍시스 독방 (대화) 11시 48분, 2017년 5월 4일 (UTC)

스페셜로 이동:기본 설정#mw-prefection-echo 및 "다른 사용자의 전자 메일"에 대해 "웹" 알림을 사용하도록 설정했는지 확인하십시오.그러면 Echo(알림이라고 함)가 누군가 당신에게 이메일 메시지를 보낼 때 wiki를 ping할 것이다.Whatamidoing (WMF)(대화) 18:44, 2017년 5월 4일 (UTC)

나는 확인했다."웹" 통지가 사용 가능으로 설정되었다.(제안해줘서 고마워)Pixis 단독 (대화) 06:21, 2017년 5월 5일 (UTC)

아마 버그 T29884("enotif는 사소한 편집 후 편집된 watchlist 페이지를 e-메일을 보내지 않는다") -- 참고: "enotif"는 watchlist 변경에 대한 알림을 이메일로 보내는 데 사용되는 코드의 이름이다.이것은 고대의 시스템이고, 우리가 페이지 상단에 있는 개인 도구모음에서 얻는 새로운 "알림" 시스템과는 완전히 별개다. 이 버그는 오래되고 복잡하며, 에노티프 시스템을 사용하는 모든 사람들을 좌절시킨다.개발자들이 최근에 그것에 대해 논의를 하고 있는 것 같으니, 그들이 그것을 해결할 믿을 만한 방법을 알아내길 바란다.

현재 가장 좋은 해결책은 정기적으로 특별 감시 목록을 방문하여 "모든 페이지를 방문으로 표시" 상단에 있는 버튼을 클릭하는 것이다.에노티프를 위해 모든 페이지를 리셋할 것이다.도움이 되길 바라며, Quiddity (WMF) (토크) 22:37, 2017년 5월 4일 (UTC)

나는 네가 충고하는 대로 했고 그들을 모두 방문자로 표시했다.감사합니다.내가 메일을 다시 받는다면 모두에게 알려줄게.Pixis 단독 (대화) 06:21, 2017년 5월 5일 (UTC)

지금까지, 잘했어.이메일을 받았는데 하루에 한 번 이상 기사가 바뀌면 한 번 변경에 한 번밖에 메일을 받지 못한다.하지만 적어도 이전보다는 나아졌어!Pixis 단독 (대화) 08:16, 2017년 5월 10일 (UTC)

모바일: 편집 저장 후 편집기로 리디렉션

편집을 모바일로 저장한 후, 이전에 편집 중인 문서의 섹션으로 보내졌다.이것은 좋고 편리하다(때로는 로드하는 방식이 뷰포트의 다른 섹션으로 귀결된다는 것을 의미하지만, 그것은 브라우저 문제임).최근에는 해당 섹션의 편집기 오프닝으로 리디렉션 중인데, 뒤로 버튼과 "편집 취소" 버튼이 작동하지 않는다.이것은 결코 내가 원하는 것이 아니며 독서를 계속할 수 있는 내 자리를 다시 찾는 것은 큰 고통이다.나는 안드로이드용 크롬과 파이어폭스에서 이런 일이 일어나는 것을 발견했다.털북숭이 친구 (토크) 2017년 5월 9일 (UTC)

혹시나 해서 팹에 올려놨어.HTH, Eltre (WMF) (대화) 08:51, 2017년 5월 10일 (UTC)

오류: 503, 백엔드 가져오기 실패

방금 오류: 503, 백엔드 가져오기가 실패하여 잠시 후에 해결되었다.내가 그 문제에 대한 세부 사항을 저장해 놓았는데, 신고해야 하고, 만약 그렇다면 어디에 있는 거야?Mathglot (토크) 00:43, 2017년 5월 10일 (UTC)

Phab과 관련될 수 있음:T164448, 다시 페이브와 관련되거나 관련되지 않을 수 있음:T164059.니르모스 (대화) 01:02, 2017년 5월 10일 (UTC)

HTTP 503 오류가 발생하기 전에 수행한 단계에 따라 다름.중복된 것일 수도 있고 아닐 수도 있다.:) 일반 정보는 mw:버그 신고 방법 --말야코 (대화) 09:19, 2017년 5월 10일 (UTC)

JS에서 최근에 변경한 ORES 필터 링크 추가

고급 사용자가 유용하다고 느낄 수 있는 작은 JavaScript 코드 조각 공유.이것은 베타 ORES 필터가 미리 구성된 RC 링크를 추가하며, 개별 파라미터를 쉽게 조정할 수 있는 방식으로 진행된다.간결성을 위한 "hidexxx=0" 매개 변수를 모두 생략했지만(그래서 Wiki의 기본값을 사용하게 됨), 변경하고 싶은 매개 변수나 기타 ORES 옵션을 쉽게 추가할 수 있다.그것은 당신의 common.js나 skin.js에 들어갈 것이고, 그 주위에 보통 mw.loader와 문서 준비 포장지가 필요하다.베타 필터는 현재 구성을 저장할 수 없고 매번 재구성하는 것이 귀찮기 때문에 이것이 필요하다(예, 브라우저 북마크는 작동하겠지만 나는 이것이 더 좋다).

mw.이용하다.addPortletLink(  'p-property',  mw.이용하다.겟술('특수:서투른 체인지스, {   피해를 주는: '나쁘다;나쁘다;매우 나쁘다',   선의의: '나쁘다;나쁘다;매우 나쁘다',   하이라이트하다: 1,   손상__색깔: 'c1',   해로운__아마도 나쁜_색깔: 'c3',   손상__색상_색채: 'c4',   해로운__매우나쁜_색깔: 'c5',   goodfaith__beauthood_color: 'c2',   좋은faith__아마도 나쁜_색깔: 'c3',   goodfaith__bad_color: 'c4',   좋은faith__매우나쁜_색깔: 'c5',  }),  '최근 변화(ORES)',  'n-n-changes-ores,  'ORES 필터가 활성화된 wiki의 최근 변경 목록',  무효의,  문서화하다.GetElementBy아이디('n-노바체인지스').넥시블링  ); 

Murph9000 (대화) 10:56, 2017년 5월 10일 (UTC)

여기에 링크된 사항 및템플릿

템플리트 사람들은 이것을 PHAB로 옮겨야 한다고 말했다.PHAB는 내가 먼저 마을 펌프를 사용해봐야 한다고 말한다.따라서 다음과 같다.

Ischik Qaaghan 또는 Template Göktürks가 포함된 페이지에서 What Links를 수행할 때 템플릿의 모든 것을 얻는다.여기서 링크하는 것의 목적은 기본 페이지에 대해 뭔가를 말해주는 페이지를 찾는 것이다.템플릿의 내용은 대개 기본 페이지에 대해 아무 말도 하지 않으며, 템플릿에서 "여기에 링크된 항목"과 별도로 찾을 수 있으며 관련 페이지를 찾기 어렵게 만들 수 있다.나는 종종 관련이 없을지도 모르는 50페이지를 검색하기 보다는 여기서 어떤 링크를 검색하는 것을 건너뛰곤 한다.이것은 점검을 어렵게 하고 우리 일의 질을 떨어뜨린다.템플리트 내용이 아닌 템플리트만을 가리키는 링크를 만들 수 있는가?이것은 중요한 관련 페이지들을 더 쉽게 확인하고 우리 일의 질을 향상시킬 것이다.벤자민 트로바토 (대화) 23:22, 2017년 5월 8일 (UTC)

벤자민 트로바토:특수에 대한 필터 실행:WhatLinks'횡단 숨기기' 같은 거 도와줄까?니르모스 (대화) 23:37, 2017년 5월 8일 (UTC)

아니, 그건 그가 찾는 게 아니야. --Izno (대화) 23:40, 2017년 5월 8일 (UTC)

리소스 검색을 사용해 보십시오. --Izno (대화) 23:40, 2017년 5월 8일 (UTC)

그리고 이것은 와 결합될 수 있다.linksto:페이지 링크를 포함한 10개의 결과. --Izno (토크) 23:46, 2017년 5월 8일 (UTC)

문제는 {{Göktürks}}이(가) 잇시크 카한과 연결돼 있기 때문에 템플릿을 초월한 모든 페이지는 잇시크 카한과도 연결돼 스페셜에 등재된다는 점이다.WhatLinksHere/Isiki Qaaghan.왓링크스이 기능은 원본에서 직접 연결되는 페이지와 변환된 템플릿을 통해서만 연결되는 페이지를 구분할 수 있는 방법이 없다.그것은 자주 요청되는 기능이다.다음은 몇 가지 요청 사항:

• 도움말 대화:여기에 링크할 내용#템플릿에서 링크를 숨기거나 표시할 수 있는 방법이 필요
• 위키백과:헬프 데스크/아카이브/2016년 9월 7일#여기에 있는 링크 -횡단 숨기기
• 위키백과:마을 펌프(기술)/아카이브 147#여기에 링크 / 템플릿
• 위키백과:찻집/질문/아카이브 328#'여기 링크된 것' 질문
• 위키백과:헬프 데스크/아카이브/2015년 3월 25일#여기에 있는 링크 필터링
• 위키백과:마을 펌프(기술)/아카이브 139#Navbox를 통한 링크를 "여기에 있는 링크"에서 제외할 수 있는가?
• 위키백과:마을 펌프(기술)/Archive 132#What Links 여기서 내비게이션으로 인해 너무 많은 목록을 생성함
• 위키백과:마을 펌프(기술)/Archive 132# 템플릿 내에서 링크와 그렇지 않은 링크를 구분하는 "여기 있는 링크"의 작업 양
• 위키백과:마을 펌프(기술)/아카이브 131#여기서 어떤 링크의 문제를 해결하시겠습니까?
• 위키백과:마을 펌프(기술)/아카이브 126#"여기서 링크할 내용"은 리디렉션에서와 같이 템플리트에서 링크를 그룹화하는 내용
• 위키백과:마을 펌프(기술)/아카이브 122#WhatLinks탐색 템플릿의 링크에 압도됨
• 위키백과:마을 펌프(제안)/아카이브 104#여기 링크 - 템플릿
• 위키백과:마을 펌프(기술)/아카이브 69#여기 및 내비게이션 상자 링크
• 도움말 대화:여기에 링크된 사항#질문.어떻게 하면 과도한 연관성을 숨길 수 있을까?
• 위키백과:헬프 데스크/아카이브/2009년 6월 20일#다음 링크
• 위키백과:헬프 데스크/아카이브/2012년 5월 9일 "여기에 어떤 링크가 있는지"-- 탐색 상자 링크를 제거할 방법이 있는가?
• 위키백과:헬프 데스크/아카이브/2011년 1월 18일# "여기에 있는 링크"에서 템플릿 링크를 필터링하는 방법
• 위키백과:헬프 데스크/아카이브/2008년 2월 25일#수신/출발 페이지 링크(백링크 및 여기에 있는 링크) 문제
• 위키백과:마을 펌프(기술)/아카이브 S#Whatlinkshere 아이디어
• 페이브리케이터:T3392: "여기 링크된 내용"은 템플릿이 포함된 모든 페이지가 아니라 템플릿 연결만 표시해야 한다."이 이미지를 사용하는 페이지"도 동일하다.
• 페이브리케이터:T5241: "여기에 있는 링크"에서 트리와 같은 결과를 생성해야 한다.
• 페이브리케이터:T14396: "여기에 링크할 내용"은 템플릿을 사용하는 페이지가 아니라 템플릿을 나열해야 함
• 위키백과 대화:WikiProject 템플릿#이러한 문제 링크

프라임헌터 (대화) 23:43, 2017년 5월 8일 (UTC)

사용자:PrimeHunter/Source links.js를 사용하여 소스에 링크가 있는 페이지를 검색하십시오.스크립트를 사용하려면 일반 JavaScript에 다음 줄을 추가하십시오.

가져오기스크립트('사용자:PrimeHunter/Source links.js'); // 링크백: [[사용자:PrimeHunter/Source links.js] 

그것은 약간의 제한이 있고 여전히 약간의 트윗을 사용할 수 있다.Regex 검색은 느리고 시간 초과될 수 있으므로 효율을 위해 mw당 linksto와 non-regex insource를 먼저 사용한다.도움말:CirrusSearch#일반 식 검색Ischik Qaaghan에서 이것을 생산한다.MediaWiki에 검색 링크를 추가하는 것도 고려할 수 있다.WhatLinks에 표시되는 링크여기 페이지.프라임헌터 (대화) 11시 46분, 2017년 5월 9일 (UTC)

나는 그 일을 추측할 것이다.linksto지시어는 대부분의 검색 속도를 현저하게 향상시키는 색인된 것이다.보통 일반 텍스트 버전(단순히 "name_of_graph"의 검색 매개 변수)을 추가하는 것도 검색 속도를 높이는 데 도움이 될 수 있다.하지만linksto대/소문자를 구분하므로 사용자에게 어떻게든 표시되어야 할 것이다. --Izno (대화) 12:10, 2017년 5월 9일 (UTC)

네가 무슨 생각을 하고 있는지 모르겠어.스크립트는 wpPageName을 사용하기 때문에linksto자동으로 올바른 케이스를 가져오지만 사용자가 나중에 수동으로 검색을 편집하면 잘못된 케이스를 작성할 수 있다.레그스insource또한 기본적으로 대소문자를 구분하며, 이 기능이 비메인스페이스 페이지에서 사용되고 소스가 네임스페이스 별칭을 사용하거나 네임스페이스의 표준 대문자를 사용하지 않는 경우 일부 페이지를 누락할 수 있다.나는 초기의 편지 케이스를 무감각하게 만들어서 [예]와 [예]가 둘 다 발견된다.전체 이름은 대소문자를 구분하지 못하게 만들 수 있다.insource:/regexp/imw:Help:CirrusSearch#Insource에서 그러나 그것은 덜 효율적이다.그것은 또한 잘못된 긍정을 줄 수 있지만, 정확한 링크가 있는 페이지만 검색되는 경우는 매우 드물 것이다.그것은 여전히 파일/이미지와 위키백과/WP와 같은 네임스페이스 별칭을 포착하지 못했다.공백 대신 밑줄을 사용하거나 링크 괄호 안에 페이지 이름 주위에 공백을 두는 것과 같이 검색을 속이는 다른 방법이 있다.이것들 중 일부는 좀 더 복잡한 골수 때문에 잡힐 수도 있지만, 그럴 만한 가치가 있는지는 잘 모르겠다.프라임헌터 (대화) 13:52, 2017년 5월 9일 (UTC)

물론, 내 생각은 만약 사용자가 (리디렉션을 통해) 모든 링크를 얻기를 원한다면, 검색하는 제목을 변경하면 된다는 것이다. --Izno (대화) 13:59, 2017년 5월 9일 (UTC)

더 좋은 예:바가카 카한에 따르면, 골자는 오르콘 비문을 건드리지 않고 템플릿에서만 관련 바흐람 초빈을 찾는 것이다.WhatLinks의 주요 목표여기 발신 링크가 없는 수신 링크를 찾는 것인데, 좋은 예를 찾을 수 없었다.벤자민 트로바토 (대화) 21:01, 2017년 5월 10일 (UTC)

WhatLinksHere/Pagename은 Pagename에서 보내는 링크를 표시하지 않는다.문제는 X페이지의 소스에서 직접 들어오는 링크와 X페이지에 표시되는 템플릿을 구분하지 않는다는 점이다.렌더링된 버전의 오르콘 비문은 하단(모바일이 아님)의 항법 템플릿에 바가 카한과의 링크가 포함되어 있으므로, 오르콘 비문은 Special:WhatLinksHere/Bagha Qahan.Bagga Qaaghan 자체에서 템플릿을 제거하는 것은 아무것도 바꾸지 않을 것이다.그러나 사용자:PrimeHunter/Source links.js는 Orkhon 비문이 검색 결과에 나열되지 않는 소스 링크를 생성한다.유사한 템플릿 버전을 만들었음{{Source links}}.{{Source links Bagha Qaghan}}Orkhon 비문 및 사용된 템플릿을 통해서만 링크되는 다른 페이지도 생략하는 소스 링크 생성.우리는 추가할 수 있다.{{Source links}}MediaWiki에서:링크: "외부 도구:특수에 리디렉션만 표시":WhatLinksHere/Bagha Qahan. insourceRegex는 비용이 많이 들고 모든 WhatLinks에 대한 높은 가시성이 있는지 여부여기 페이지(다른 인터페이스 언어를 가진 등록된 사용자 제외)는 성능 문제를 일으킬 수 있다.에 대한 필터링으로 시작한다.linksto내 생각에 그것은 엄청난 수의 링크가 들어오는 페이지의 심각한 문제일 뿐이다.프라임헌터 (대화) 21:50, 2017년 5월 10일 (UTC)

뉴스 편집 #1—2017

다른 언어로 읽기 • 이 다국어 뉴스레터 구독 목록

알고 있었어요?

변경 사항을 시각적으로 검토할 수 있다는 사실을 알고 있었는가?

페이지 편집을 마쳤으면 편집 요약을 입력한 다음 "변경 내용 검토"를 선택하십시오.

시각적 모드에서는 추가, 제거, 새 링크 및 형식이 강조 표시된 것을 볼 수 있다.이미지의 크기 변경과 같은 다른 변경 사항은 측면의 메모에 설명되어 있다.

전환 버튼을 클릭하여 시각적 차이와 Wikitext 차이 사이를 전환하십시오.

Wikitext diff는 wikitext 편집자와 페이지 기록에 사용되는 것과 동일한 diff 도구다.

시각적 편집기 사용 방법에 대한 자세한 정보를 제공하는 사용자 가이드를 읽고 번역할 수 있다.

마지막 뉴스레터 이후 VisualEditor 팀은 대부분의 시간을 Visual Editor 내부에서 베타 기능으로 사용할 수 있는 2017 wikitext 편집기 모드를 지원하고 새로운 시각적 확산 도구를 추가하는 데 보냈다.그들의 작업판은 파브리케이터에서 구할 수 있다.매주 완료되는 작업에 대한 링크를 mw:VisualEditor/주간 평가 회의현재 우선순위는 버그 수정, 2017년 위키텍스트 편집기 베타 기능 지원, 시각적 확산 툴 개선이다.

최근 변경 사항

새로운 Wikitext 편집 모드는 데스크톱 장치에서 베타 기능으로 사용할 수 있다.2017 wikitxt 편집기는 비주얼 편집기와 같은 툴바를 가지고 있으며 시트로이드 서비스와 기타 현대적인 도구를 사용할 수 있다.스페셜로 이동:기본 설정#mw-prefection-betafeatures를 사용하여 새 wikitext 모드를 활성화하십시오.

VisualEditor의 Visual 모드에서 새로운 시각적 확산 도구를 사용할 수 있다.Wikitext와 시각적 차이 사이를 전환할 수 있다.나중에 여기에 더 많은 기능이 추가될 것이다.향후 이 툴은 다른 미디어위키 컴포넌트에 통합될 수 있다.[8]

그 팀은 각주 리스트에 대한 다중 열 지원을 추가했다.그<references />블록은 넓은 화면의 열에 있는 긴 참조 목록을 자동으로 표시할 수 있다.이것은 각주를 읽기 쉽게 만든다.Wiki에 대한 다중 컬럼 지원을 요청할 수 있다.[9]

기타 변경 사항:

• 이제 웹 브라우저의 기능을 사용하여 새로운 wikitxt 모드에서 입력 방향을 전환할 수 있다.이것은 특히 자바스크립트나 CSS를 써야 하는 우르두나 히브리어와 같은 RTL 언어 사용자에게 유용하다.Command+Shift+X 또는 Control+를 사용할 수 있음Shift+X를 눌러 트리거하십시오.[10]
• 시각적 편집 모드와 Wikitext 편집 모드 사이를 전환하는 방법은 이제 일관된다.두 가지 옵션을 보여주는 드롭다운 메뉴가 있다.이것은 이제 데스크탑과 모바일 웹 편집에서, 그리고 Flow와 같이 편집을 포함하는 내부에서도 마찬가지다.[11]
• 더 빠른 액세스를 위해 카테고리 항목을 페이지 옵션 메뉴의 맨 위로 이동(아이콘 클릭에서)했다.[12] 또한 "이 페이지에서 사용하는 템플리트" 기능이 있다.[13]
• 이제 만들 수 있음<chem>태그(때로는 다음과 같이 사용됨)<ce>시각적 편집기 내부의 화학 공식에 대한 설명. [14]
• 테이블은 접히거나 접히지 않은 것으로 설정할 수 있다.[15]
• Special character 메뉴에는 캐나다 원주민의 음절과 각도 따옴표( (‹, ⟨⟩)의 문자가 포함되어 있다.팀은 자원 개발자 Tpt.[16]에게 감사한다.
• 버그로 인해 일부 섹션 편집 충돌이 발생하여 페이지의 나머지 부분이 비어 있다.이것은 이미 고쳐졌다.그 팀은 방해해서 미안하다.[17]
• 인용문을 위한 새로운 바로 가기 키가 있다.Control+Shift+KPC에서 또는Command+Shift+K맥으로링크 만들기를 위한 키보드 단축키를 기반으로 하는데, 이 기능을 기반으로 한다.Control+KPC나Command+K맥에서. [18]

미래 변화

• VisualEditor 팀은 Community Tech 팀과 함께 구문을 강조 표시하는 도구를 작업하고 있다.다음 중 일치하는 쌍을 강조한다.<ref>태그 및 기타 유형의 Wikitext 구문.켜고 끌 수 있을 겁니다.VisualEditor의 내장 Wikitext 모드에서 처음 사용할 수 있으며, 아마도 2017년 후반에 사용할 수 있을 것이다.[19]
• 미리보기 표시, 변경사항 표시 및 편집 완료에 사용되는 버튼의 종류는 모든 WMF 지원 위키텍스트 편집기에서 변경된다.새로운 버튼은 OOjs UI를 사용할 것이다.버튼은 더 크고, 더 밝고, 읽기 쉬울 것이다.라벨은 그대로 유지될 것이다.페이지를 편집하고 추가함으로써 새 단추를 테스트할 수 있다.&ooui=1URL의 끝까지 다음과 같이: https://www.mediawiki.org/wiki/Project:Sandbox?action=edit&ooui=1 지역 CSS가 변경되더라도 더 이상 이전 모습은 가능하지 않을 것이다.[20]
• 구시대적인 2006년 위키텍스트 편집자는 올해 말에 삭제될 것이다.약 0.03%의 활성 편집자가 사용하고 있다.어떤 편집 도구를 사용할지 확실하지 않은 경우 mediawiki.org의 편집 도구 목록을 참조하십시오.[21]

만약 당신이 원하는 언어로 이것을 읽지 않는다면, 번역하는 것을 도와줘!다음 호가 준비되면 통지할 수 있도록 번역자 메일 목록을 구독하거나 당사에 직접 문의하십시오.고마워!사용자:WMF(Whatamidoing)(대화) 19:18, 2017년 5월 9일 (UTC)

빅 블루 버튼은 페르시아어 위키피디아에 방금 배치되었다.https://fa.wikipedia.org/wiki/Special:Random?action=edit&uselang=en은 임의의 기사를 위해 당신을 편집 창으로 데려가야만 변경 사항을 볼 수 있다.이러한 변경은 이전 Wikitext 편집기에만 영향을 미치며, 결과적으로 가젯이나 스크립트를 업데이트해야 할 수도 있다.이 변경에 대응하여 하나의 스크립트가 어떻게 조정되었는지 보려면 이 차이점을 참조하십시오.Whatamidoing (WMF) (토크) 22:07, 2017년 5월 11일 (UTC)

ISBN 인용구들이 이제 오토필과 함께!

안녕하십니까, 위키미디어 재단의 위키백과 도서관 프로그램에서 우리는 OCLC와 협력하여 자동 채운 ISBN 인용문들을 그들의 월드캣 데이터베이스를 통해 이용할 수 있도록 하고 있다.모든 언어 위키피디아에 이 기능을 배치했다. Wikimedia 블로그에서 자세히 알아보십시오. https://blog.wikimedia.org/2017/05/11/wikimedia-oclc-partnership/

건배, 제이크 오카시 (WMF) (토크) 19:54, 2017년 5월 11일 (UTC)

니스!--S 필브릭(토크) 22:43, 2017년 5월 11일 (UTC)

이것은 mw:citoid 서비스의 새로운 특징이다.현재 VisualEditor(시각적 및 Wikitext 모드)에서 사용할 수 있다.미래에는 2010 위키텍스트 편집기로 통합될 것이다.Whatamidoing (WMF) (토크) 01:22, 2017년 5월 12일 (UTC)

사용자 지정 시그니처 설정 도움말

사용자 대화에서 다른 사람이 조언해 주시겠습니까?아메틀링1125#서명?고마워요.비블브록스 (대화) 07:05, 2017년 5월 12일 (UTC)

완료. Graham87 07:30, 2017년 5월 12일 (UTC)

위키백과에 대한 몇 가지 질문:템플릿_limits

1. $wgMaxIriterSize를 두 변수에 분할할 수 있는가?

   파싱할 때 페이지 크기를 저장할 수 있고 위키코드 크기를 확장할 수 있는 변수인 것 같다.변수를 추가하여 이 변수의 기능을 분할할 수 있는가?아마도 $wgMaxInitialSize는 페이지의 크기를 저장할 수 있고 새로운 것은 크기를 확장하는 것을 제어한다.

2. wmf의 생산 환경에서 $wgMaxIriterSize가 4MB(현재 가치의 시간, 2MB)로 설정되면 어떻게 되는가?

   왜 2MB가 확장 사이즈로 설정되어 있는지 이해할 수 없어.그리고 4MB라면 생산환경에 어떤 문제가 생길까?zh.wp에 있는 몇몇 큰 Navbox나 Infobox로 페이지를 쉽게 깨기 때문에, 나는 그것을 피하기 위해 더 큰 크기를 요청하고 싶다.나는 실현가능성을 확인하기 위해 몇 가지 제안과 정보가 필요하다.

그게 다야고마워. --Cwek (대화) 07:12, 2017년 5월 11일 (UTC)

개발자 모자를 착용한 상태에서: 템플릿이 페이지 크기에 대한 해결책으로 전환되는 것을 방지하기 위한 것이다.우리는 2MB의 Wikitext 페이지들이 일부 사용자들이 로드하는 데 골칫거리인 엄청난 HTML 출력으로 귀결되는 것을 더 이상 허용하지 않는다. 이 문제를 더 이상 이 문제를 악화시키지 말자.맥스 세메닉 (토크) 18:18, 2017년 5월 11일 (UTC)

제안해주셔서 감사합니다. --Cwek (대화) 02:07, 2017년 5월 12일 (UTC)

@Cwek: 정말 어디선가 한계에 부딪힌 적이 있는가?위와 같은 이유와 성능의 한계를 갖는 것에 동의하며, 2MB는 상당히 넉넉한 한계로 느껴진다.어딘가에서 문제를 일으키고 있다면, 템플릿과 마크업을 도와서 무언가를 제한치 이내로 유지할 수 있을 것이다(관련된 기본 내용이 실제로 합리적이고 다소 무거운 다듬기나 쪼개기가 필요하지 않다고 가정할 때).Murph9000 (대화) 08:17, 2017년 5월 12일 (UTC)

모바일 장치에서 편집할 수 없음

내가 오늘 아침에 일어나서 내가 편집하는 기사에 대한 몇 가지 진행중인 토론으로 체크인을 했을 때, 나는 많은 기사들이 모든 부분을 확장하고 편집은 불가능하다는 것을 알았다.2017년 월드랠리챔피언십 같은 기사는 편집할 수 있지만 2017년 포뮬러원 시즌 같은 기사는 편집할 수 없다.포로몬키 (대화) 09:48, 2017년 5월 12일 (UTC)

좋아, 일단 고쳐진 것 같아.포로몬키 (대화) 10:04, 2017년 5월 12일 (UTC)

편집 충돌이 왜 그래?

그래서 오늘 편집 충돌이 생겼고, 내가 본 것과는 아주 다른 메세지가 나타났어.스크린샷을 찍었어야 했는데 안 찍었어.어쨌든, 그것은 내가 예상한 대로 행동하지 않았고 내가 변화를 저장하도록 내버려두지 않았다.더 실험해 보고 싶지만, 의도적으로 편집 충돌을 일으키기는 어렵다.다른 사람이 아주 다른 편집 충돌 메시지를 받았거나, 이것에 대해 아는 것이 있는가?나는 사람들이 편집 분쟁에 대한 개선된 처리를 요청했던 지역 사회 위시리스트와 관련이 있다고 생각하지만, 내가 본 것은 개선이 아니었기 때문에 정확히 무엇이 실행되었는지에 대한 더 많은 문서화를 보고 싶다.~ ONUnicorn^{(Talk Contribs)} 문제 해결 15:22, 2017년 5월 12일(UTC)

@ONUnicorn: 새로운 "Two column edit conflict conflict" 베타 기본 설정을 켰는가?네가 그걸 보는 것 같구나.샘 월튼 (대화) 15:24, 2017년 5월 12일 (UTC)

"모든 새로운 베타 기능을 자동으로 활성화"를 확인했으므로, 아마도그렇게 말해줘서 고마워.~ ONUnicorn^{(Talk Contribs)} 문제 해결 15:28, 2017년 5월 12일 (UTC)

이 기능은 #Beta Feature Two Column Edit Conflict 뷰에서 발표되었다.프라임헌터 (대화) 2017년 5월 12일 15시 30분 (UTC)

누가 뭐 망가뜨린 거야?

…아니면 나만 그런가?호버팁은 모든 페이지에 대해 "이 페이지에 대한 미리보기가 없는 것처럼 보인다"라는 메시지를 준다.DYK Check는 모든 페이지 크기를 0바이트로 제공한다; Chrome이 아닌 Safari에서는 "API 오류" 메시지도 받는다.누군가 먼저 테스트하지 않고 무언가를 바꿨나?Justlettersandnumber (대화) 15:13, 2017년 5월 12일 (UTC)

너뿐만 아니라, 너도 보고 있어.Mathglot (토크) 16:57, 2017년 5월 12일 (UTC)

모든 것이 순서대로 되어 있음에도 불구하고 Google에서 색인화하지 않는 기사

저명한 달릿 트랜스젠더 활동가인 그레이스 바누는 트랜스젠더 여성 최초로 인도 타밀 나두의 한 대학에서 공학 학위를 취득했다.아주 깔끔한 사람.하지만 내가 시도했던 모든 것에도 불구하고, 구글에서 "Grace Banu"나 더 이상 미스터리하게 "Grace Banu site:en.wikipedia.org"을 검색했을 때, 그리고 심지어 "Grace Banu site:https://en.wikipedia.org/wiki/Grace_Banu"을 검색했을 때도, 그것은 단순히 나타나지 않는다.기사:

• C 클래스 및 3개의 위키백과 제목
• 12개 이상의 레퍼런스를 보유하고 있음
• 12개 범주에 속함
• 템플릿 경고 없음
• 적절한 사용자 데이터 정렬 포함
• Wikidata 항목 있음
• 고아가 아니며 여러 목록에서 연결됨

왜 이 기사가 보이지 않는지 알아?고마워!제이크 오카시 ^{t c} 17:11, 2017년 5월 12일 (UTC)

페이지 정보에 색인이라고 되어 있는데, 이건 구글 오류인 것 같은데?샘 월튼 (대화) 17:17, 2017년 5월 12일 (UTC)

구글에 그 페이지를 기어와 인덱싱해달라는 요청을 제출했고, 응답했다. 당신의 요청은 접수되었고 곧 처리될 것이다.— Xaosflux^Talk 17:38, 2017년 5월 12일(UTC)

새로운 기사들은 30일 동안 또는 그것들이 순찰을 돌 때까지 자동적으로 no-index를 받는다.위키백과 참조:검색 엔진 인덱싱 제어#아티클의 색인화("메인 스페이스")그레이스 바누는 2017년 4월 15일에 만들어졌으며 여전히 인덱스가 없다.새로운 페이지를 자동으로 색인화하는 기능은 비교적 새로운 것이며 색인화를 제어하는 다른 방법만을 확인하는 "페이지 정보"의 주장과 조정되지 않았다.프라임헌터 (대화) 17:38, 2017년 5월 12일 (UTC)

(충돌 편집)이 새 페이지는 아직 검토되지 않았다. 특별:새 페이지피드는 그것이 아직 미결 상태임을 보여준다 - 그것은 검토될 때까지 또는 한 달이 될 때까지 유지될 추가적인 노지수를 가지고 있다.— Xaosflux^Talk 17:42, 2017년 5월 12일(UTC)

나는 지금 그것을 검토했다.[22] 역시,noindexhtml 원본에서 제거됨.프라임헌터 (대화) 17:45, 2017년 5월 12일 (UTC)

감사 프라임헌터 - 다른 사용자에게는 새 페이지 리뷰를 위한 방대한 백로그가 여전히 존재한다는 점을 유의하십시오. 이 영역에서 도움을 받으려면 WP에 들르십시오.NPP는 방법을 배울 것이다.— Xaosflux^Talk 17:47, 2017년 5월 12일(UTC)

이것을 제어하는 설정은$wgPageTriageNoIndexUnreviewedNewArticles, mw:확장:페이지트리지#확장 구성.기본적으로 거짓이지만 https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php과 https://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php의 Wikimedia에 대해 사실로 설정되어 있다.이 기능은 다음과 같이 소개되었다.2016년 10월 T147544."페이지 정보"로 조정을 요청하기 위해 버그를 신청해야 하는가?프라임헌터 (대화) 17:58, 2017년 5월 12일 (UTC)

PrimeHunter 내 생각에 이 지수화 상태를&actin=info 순 양수일 뿐 - 아마도 현재 구성/오버라이드/허용되지 않은 각 인덱스 컨트롤의 목록과 "순 결과"가 무엇인지일 것이다. — xaosflux^Talk 18:35, 2017년 5월 12일(UTC)

나는 pab을 만들었다.T165204: "페이지 트라이어지가 새로운 기사에 대한 색인화를 야기할 때 페이지 정보 청구가 허용된다."프라임헌터 (대화) 21:43, 2017년 5월 12일 (UTC)

새 외부 MediaWiki 편집기

얘들아, 나 지금 조금 전에 외부 미디어위키 편집기 작업을 하고 있는데, 예비 피드백을 받고 싶어.이쪽에 있다.잘 들어, 베타 버전이지만, 이런 도구에서는 어떤 기능이 유용할지, 또 어떤 기능이 있는지 알고 싶어.명심해, 이 편집기는 미디어위키 마크업을 "진정적으로" 파싱하기 때문에 꽤 다르게 작동하는데, 이것은 그것이 단순히 망가진 것을 보여주는 대신에 오류를 발생시킨다는 것을 의미한다.누구든, 미리 고마워!드루머트 (^ᴥ^)토크 23:57, 2017년 5월 9일 (UTC)

편집자는 더 필요 없고, 일부는 덜 필요하다고 할 수도 있다. --Redrose64 🌹 (토크) 07:35, 2017년 5월 10일 (UTC)

드류트, 주어진 위키텍스트 조각을 어떻게 구문 분석해야 할지 어떻게 결정하셨나요?Whatamidoing (WMF) (토크) 15:51, 2017년 5월 10일 (UTC)

@Whatamidoing (WMF): 대부분 Parsoid로부터 단서를 얻어 불완전한 Mediawiki BNF 문서에 관한 문서를 가져갔다.나는 MW 마크업이 해석에 맡겨져 있다는 것을 이해하지만, 그래서 렉서는 꽤 관대하다.드루머트(^ᴥ^)토크 19:45, 2017년 5월 10일 (UTC)

mw:에도 관심이 있을 수 있다.구문 분석/교체 정리 및 관련 페이지.올해는 꽤 많은 변화가 일어나고 있다.대부분의 경우 파르소이드를 따르는 것이 비교적 안전한 접근법이 될 것이라고 생각한다.Whatamidoing (WMF) (토크) 16:27, 2017년 5월 11일 (UTC)

좋은 정보!생각해보니 MW가 아마도 내 논의에 더 적합한 장소일 것이다.드루머트 (^ᴥ^)토크 19:29, 2017년 5월 11일 (UTC)

@Redros64:그것에 대해 좀더 많은 맥락을 줄 수 있겠니?드루머트(^ᴥ^)토크 19:29, 2017년 5월 11일 (UTC)

@Drewmutt:2003년 시대의 위키텍스트 편집자, 2010년 위키텍스트 편집자, 2017년 소스 편집자, WikEd, 자바스크립트와 루아 페이지에 사용되는 "코드 편집자", 시각적 편집자, 찻집 사람들이 좋아하는 것, 플로우와 함께 제공되는 것.한 개만 있으면 충분할 때 8개를 만든다: 우리는 아직 배울 필요가 없다. --Redrose64 🌹 (토크) 19:33, 2017년 5월 12일 (UTC)

@Redrose64: 아마 놀랄 일도 아닌 것 같은데, 나는 진심으로 동의하지 않는다.각자 자신의 장점과 단점을 가져온다고 느낀다.그래서 당신이 무수한 편집자들을 보는 거라고 나는 믿는다.빨리 바꿔야 할 것이 있는가?비주얼 에디터.참조 이슈를 파고들 필요가 있는가?원본 편집기를 사용하십시오.편집자의 다양성과 필요성 때문에, 나는 사실 그 이상이 없다는 것이 놀랍다.어제 시험해 본 결과 다른 편집자가 제공하지 않는 서비스인 도널드 트럼프 기사에 오류가 있는 것으로 나타났다.게다가, 공평하게 말하면, 아무도 어떤 것도 배우게 하지 않는다.드루머트 (^ᴥ^^) 대화 20:42, 2017년 5월 12일 (UTC)

편집자가 자바 설치를 요구하는가?나는 수년 전에 자바를 버렸고, 그것이 보안의 악몽이라는 것이 명백해졌다.그것의 현재 상태는 편집자를 시험해 보고자 하는 모든 사람들을 위한 고려사항이어야 한다.조누니크 (대화) 23시 20분, 2017년 5월 12일 (UTC)

@요누니크:엄밀히 말하면, 인텔리제이가 JRE/JDK 번들을 가지고 있기 때문에. 하지만 보안 관점에서 그게 더 나은지 모르겠어.드루머트 (^ᴥ^)토크 00:38, 2017년 5월 13일 (UTC)

감시 목록 오류

내 감시 목록에 페이지를 추가하려고 했는데, 이런 오류 메시지를 받았어: 모바일-프론트 엔드-워치리스트-오류. 왜 이런 일이 발생하는지 아는 사람 있어?레기미그레고8 (토크) 13:49, 2017년 5월 12일 (UTC)

MediaWiki:모바일 프런트엔드-워치리스트 오류="이 페이지를 보는 데 문제가 있었다.다시 시도하십시오."너 모바일 버전 했었니?다시 해보셨나요?그래도 안 되면 어느 페이지인데 다른 페이지도 되는 거야?프라임헌터 (대화) 14:16, 2017년 5월 12일 (UTC)

모바일, 여러 페이지를 여러 번 시도해 봤지만, 페이지는 작동하지 않았다.레고미그레고8 (토크) 14:24, 2017년 5월 12일 (UTC)

데스크톱은 작동하지만 모바일은 나에게도 실패한다.Microsoft Edge와 Firefox 모두에서 "모바일-프론드-워치리스트-오류"가 발생하는데, 여기와 공용에서 모두, 그리고 일반 계정과 빈 워치리스트가 있는 대체 계정에서 모두입니다.프라임헌터 (토크) 15:06, 2017년 5월 12일 (UTC)

목요일에는 특정 브라우저(안드로이드용 Firefox)의 이러한 문제를 해결하기 위한 변경사항이 생방송으로 진행되었지만, 그 대신 더 악화시킨 것으로 보인다.나는 다음과 같은 내용을 정리했다.T165209.Tbayer (WMF) (토크) 00:58, 2017년 5월 13일 (UTC)

범주에서 이상한 점:도움을 구하는 위키백과 사용자

카테고리:에 나타난 도움말 요청에 응답한 경우:도움을 구하는 위키백과 - 응답한 후에야 데이터 스탬프를 볼 수 있었고, 내가 응답하고 있던 템플릿은 2015년 10월에 다시 배치되었다.어떻게 지금까지 그 범주에 나타나지 않았을까?윤수이 10시 57분, 2017년 5월 11일 (UTC)

템플릿을 추가하기 위해 편집한 후 링크를 업데이트하는 작업은 2015년에 손실되었을 가능성이 높았고, 최근에 이 페이지에 대한 다른 작업을 촉발했다.무엇이 그것을 촉발시켰는지에 대해서는, 확실히 알 수 있는 방법은 없을 것이다(그러나 그것은 모듈의 최근 편집일 수도 있다).ping 금지).Anomie⚔ 18:48, 2017년 5월 11일 (UTC)

정말 이상하다, 2017년 2월에 {{help me}}의 전횡을 모두 거쳤는데, 여기 링크에서...– Train2104 (t • c) 20:02, 2017년 5월 11일 (UTC)

범주 구성원 자격을 업데이트하지 못한 작업은 또한 해당 페이지의 템플릿 전용 기록을 업데이트하지 못했을 것이다.Anomie⚔ 11:53, 2017년 5월 13일 (UTC)

툴이 OAuth를 통해 Watchlist를 읽고 변경할 수 있는가?만약 그렇다면, 누군가가 그것을 만들고 싶어할까?

안녕.WT에 대한 토론에서 출발했다.Twinkle, Cabayi는 당신의 감시 목록에서 닫힌 XFD와 SPI를 자동으로 제거하는 아이디어를 내놓았다.OAuth가 당신의 워치리스트를 읽는 것을 허락하는가?그리고 만약 그렇다면, 누군가가 워치리스트를 읽고, 특정 종류의 모든 페이지(XFD, SPI 등)를 걸러내고, 그것들이 여전히 열려 있는지(그리고 열려 있지 않다면 제거)하는 도구를 만들 수 있을까?나는 전문가는 아니지만, 어떤 기술을 가진 사람에게 그것은 그리 어렵지 않을 거라고 생각해.SoWhy 12:57, 2017년 5월 12일(UTC)

예, OAuth 소비자는 "당신의 감시 목록 보기"와 "당신의 감시 목록 편집" 보조금을 부여하면 감시 목록을 보고 편집할 수 있다.Anomie⚔ 11:56, 2017년 5월 13일 (UTC)

importScript

그래서 나는 그 유산의 지위와 미래의 퇴폐에 대해 생각해 보았다.importScript()한동안 떠돌던 .제안된 교체 시간(mw):ResourceLoader/레거시 JavaScript:

mw.짐을 싣다.짐을 싣다( '/w/index.php?title=미디어위키:가젯-핫캣.js&action=raw&ctype=text/javascript'' ); 

이제, 코더로서, 그것은 나에게 좋은 대체품으로 느껴지지 않는다.위키 페이지 이름을 붙이는 것에 비하면 부정해 보일 뿐이다.응, 기능적이고 효과가 있지만 못생겼어.그래서 나는 다음과 같은 것을 생각해 냈는데, 그것이 (혹은 이와 비슷한 것) 현지 스크립트 로딩에 제안된 대체품이 아닌 타당한 이유가 있는지 궁금하다.

mw.짐을 싣다.사용.( 'mediawiki.util' ).그때( 기능을 발휘하다 () {  시합을 하다 loadParamsJS = {   액션: raw'   : '텍스트/텍스트'  };  시합을 하다 로드스크립트 = 기능을 발휘하다 (페이지를 매기다) {   .짐을 싣다.짐을 싣다( .이용하다.겟술( 페이지를 매기다 loadParamsJS ));  };   로드스크립트( 사서:jp:s:풀슨.js' );  로드스크립트( '사용자:예:/Fulminator.js' );   로드스크립트( '사용자:예/마크 III.js' );  … }); 

보이는 원시 URL도 없고, 해킹 같은 문자열 조작도 없고, 단지 (희망적으로) 사용할 수 있는 라이브러리 기능을 잘 활용하는 깨끗한 코드.쉽게 확장되어loadStylesheet()기능을 발휘하다그래서, 그것에 대한 생각은, 내가 장애물을 발견하는 데 실패했는가?로컬 스크립트 로딩에 대한 가능한 대체 항목으로 MW 문서에서 제안되지 않는 이유(인터위키 링크가 무엇인지 모르므로 로컬 전용임)가 있는가?

Murph9000 (대화) 13:06, 2017년 5월 13일 (UTC)

나는 둘 다 정말 좋아하지 않는다.문제는 사용자 설명서의 사용이 실제로 가젯을 활성화하는 것만큼 간단해야 한다는 것이다.그리고 현재 그것은 그렇지 않고, 이 타락과 함께 그것은 더 악화될 것이다.최근 들어 User와 같은 사용자)와 비슷한 생각을 하고 있다.Equazcion/ScriptInstaller를 선택한 다음 common.js에 'importScript' 문을 추가하는 대신 사용자 기본 설정에 기록하도록 하십시오.그런 다음 사이트 전체 가젯을 사용하여 값을 읽고 스크립트를 로드하십시오.우리는 쉽게 사람들의 기존 스크립트 페이지를 읽고 변환을 안내하는 또 다른 장치를 만들 수 있었다.크링클이 어떻게 생각하는지 궁금하군...—DJ (대화 • 기여) 13:35, 2017년 5월 13일 (UTC)

@TheDJ: 사용자 개인 설정이기 때문에 다른 사람이 도움을 제공하거나 수정하는 능력을 심각하게 제한하는 선호를 그대로 사용하는 발상이 마음에 들지 않는다 — xaosflux 14:08, 2017년 5월 13일 (UTC)

UTF8 인코딩

나의 봇은 크리오루스를 처리하려고 할 때 쓰레기를 만든다.예를 들어, 맨 위는

native_name = ирус

..봇 생산물들

native_name = ￐ﾚ￑ﾀ￐ﾸ￐ﾾ￐ﾠ￑ﾃ￑ﾁ

봇은 사양에 따라 UTF-8이지만, 그 기사는 UTF-16/32 문자를 포함하고 있는 것처럼 보입니까?이것이 정확하다고 가정할 때, 어떻게 고치겠는가? -- GreenC 19:13, 2017년 5월 13일 (UTC)

KrioRus의 native_name은 ru에서 사용되는 제목과 이름과 일치하는 것으로 나타난다.ир 코브롤할로스와 나의 편집자는 기사에서 UTF-8이 깨진 것에 대해 불평하지 않기 때문에 내 추측으로는 문제는 봇에 있는 것 같다.나의 "일치할 것"은 두 기사를 각각 다른 파일에 다운로드하고 텍스트 덤프를 비교하는 도구를 사용하는 것에 기초한다.나는 그것이 믿을만하다고 생각하지만 실제로 시험해 보지 않았다.그 봇은 영어 이외의 문자로 된 다른 기사에도 효과가 있는가?조누니크 (대화) 01:43, 2017년 5월 14일 (UTC)

W3 validator가 완전히 복구되고 페이지 인코딩(<meta charset="UTF-8"/> )은 UTF8에 대해 선언됨 — xaosflux^Talk 02:00, 2017년 5월 14일(UTC)

그래, 이상해, 내가 유일하게 문제 삼은 기사인데다가 봇이 10만 개의 기사를 처리해 버렸어.자, 처음부터 다시. -- GreenC 02:41, 2017년 5월 14일 (UTC)

알아냈어, 일종의.내 봇의 서식 수정 중 하나가 키릴어 관련 문자로 인해 가비지 UTF-16/32 문자를 생성했는데, 이로 인해 전체 문서를 UTF-16/32로 해석하는 다른 것이 발생하였다. -- GreenC 03:07, 2017년 5월 14일(UTC)

인용문 템플릿

내가 여기서 뭘 잘못하고 있는지 누가 좀 말해줄래?

Suarez, David L. (2009). [‬https://books.google.com/books?id=eZjFavPmuxAC&pg=PA3 "Influenza a Virus"]. In ‪David E. Swayne (ed.). Avian Influenza. John Wiley & Sons. p. 3. ISBN ‪9780813818665.{{cite book}}: Check value (도움말);확인 값: 잘못된 문자(도움말)
고마워. 아무거나 (대화) 22시 45분, 2017년 5월 14일 (UTC)

14자가 나온다. isbn=‪9780813818665. 첫 번째 문자는 눈에 보이지 않는 문자 U+202A 좌우에 유니코드 문자가 내장되어 있다.다른 곳에서 이 억만장자를 복사해서 붙여놨어?

—스승 (대화) 22:56, 2017년 5월 14일 (UTC)

본질적으로 같은 문제 chapter-url=첫 번째 문자(역시 보이지 않음)가 U+202C 팝 방향 포맷 유니코드 문자라는 점을 제외하고.

—스승 (대화) 23:01, 2017년 5월 14일 (UTC)

답장 고마워, 사용자:스님을 트라피스트하십시오.보이지 않는 캐릭터들을 제거했는데 아직도 좀 엉망이네

Suarez, David L. (2009). "Influenza a Virus". In ‪David E. Swayne (ed.). Avian Influenza. John Wiley & Sons. p. 3. ISBN 9780813818665.
Anythingyyouwant (대화) 23:20, 2017년 5월 14일 (UTC)

U+202C 위치 14.url과 isbn은 어디서 구하는거야?Google이나 다른 웹 사이트가 무언가를 변경했기 때문에 이러한 문제가 자주 발생할 경우, 모듈을 수정하고 수정하십시오.이러한 특정 문자를 탐지하는 인용문/CS1

—스승 (대화) 23:33, 2017년 5월 14일 (UTC)

다시 한 번 고마워.여기서 ISBN을 복사했다(페이지 하단).URL로 이동하여 화면 상단의 상자에 있는 자료를 복사하여 URL을 복사하십시오. Anythingyyouwant (대화) 23:49, 2017년 5월 14일 (UTC)

보이지 않는 캐릭터들은 구글에서 온 것이 아닌 것 같다.템플릿 자체는?다 타이핑한 거야, 아니면 어디다 복사해서 작성한 거야?사용 가능한 인용문 작성 도구 중 하나를 사용하셨습니까?

—스승 (대화) 00:06, 2017년 5월 15일 (UTC)

내 아이폰에 처음부터 입력했지만 URL과 isbn을 붙여넣었다. Anythingyyouwant (대화) 00:15, 2017년 5월 15일 (UTC)

흠. 어리둥절해.의 첫 번째 문자 editor=‪David E. SwayneU+202A 캐릭터 입니다.복사/붙여넣기?

—스승 (대화) 00:40, 2017년 5월 15일 (UTC)

응. 구글에서 복사해서 내 아이폰에 "Notes"에 붙여놨어.그리고 나서 "Notes"에서 위키피디아로 복사했다. Anythingyyouwant (대화) 00:53, 2017년 5월 15일 (UTC)

"또는 섹션 편집"

기사를 볼 때 왜 자꾸 이 대화 상자가 뜨는 거지?샘 월튼 (대화) 18:03, 2017년 5월 13일 (UTC)

@Samwalton9:최근의 기여는 다음과 같다. (Tag: 2017 source edit)그곳은 찾기 시작할 것 같다(예를 들어, 베타 버전을 비활성화하고, 무슨 일이 일어나는지 살펴봐).Murph9000 (대화) 18:21, 2017년 5월 13일 (UTC)

정말 - 어쨌든 지금은 사라진 것 같다.샘 월튼 (대화) 18:36, 2017년 5월 13일 (UTC)

이것에 대해 더 말해줄 수 있니?(스크린샷을 다시 트리거할 수 있는 경우 이상적일 수 있음그 구절은 미디어위키에서 온 것 같다.Guided tour-tour-gettingstarteddasktoolbar-edit-section-title/en, Guided Tours(요즘에는 사용하지 않는 것 같던 가이드 투어)의 일환이다.Whatamidoing (WMF) (토크) 15:34, 2017년 5월 15일 (UTC

@Whatamidoing (WMF): 이제 없어졌으니 기억에서 해야겠다.며칠 전에 새로운 소스 편집기를 활성화한 후, "또는 섹션 편집" 머리글이 있는 상단 섹션에 연결된 팝업 상자와 상자 안에 있는 정보 텍스트를 보기 시작했다고 생각한다.도입부 연속상자의 마지막 상자인 것 같았고, 다른 상자들을 보았는지 기억이 나지 않는다(그런 것 같지만 정확히 기억은 나지 않는다).GuidedTour - 특히 그 비디오를 보면서 - 내가 본 것이 바로 그것인 것 같다.샘 월튼 (대화) 17:03, 2017년 5월 15일 (UTC)

위키백과 대화:위키프로젝트 자바스크립트#난처하다.나중에 뷰포트의 위치를 변경하려면 뷰포트에 위치를 저장하려면 어떻게 해야 하는가?

나는 뷰포트 위치 조정 문제에 갇혀 있다.이게 네가 친숙한 거라면 네 도움이 필요할 거야.트랜스휴머니스트 2017년 5월 15일 (UTC)

목록 정리

자이나주의 관련 기사 색인에서 리디렉션 및 삭제/업데이트된 페이지를 대체할 수 있는 봇이나 스크립트가 있는가?또한 링크에서 [Some page This label]을(를) 제거하는 스크립트가 있는가?— Capankajsmilyo가 추가한 선행 미서명 논평 (대화 • 기여) 06:23, 2017년 5월 7일 (UTC)

아니, WP:파손되지 않은 상태 및 WP:코스메틱BOT는 둘 다 리디렉션의 무분별한 우회 행위를 금지하고 있다. --Redrose64 🌹 (대화) 08:20, 2017년 5월 7일 (UTC)

이 정책들은 기사를 위한 것이다.그들은 리스트에 적용되니?거기에서는 언급되지 않는다. -- Pankaj Jain Capankajsmilyo (talk · 기여 · 계수) 12:16, 2017년 5월 7일 (UTC)

왜 당신은 그것들이 기사에만 적용된다고 생각하는가?아니면 왜 (기사의 하위 등급인) 리스트에 적용되지 않는다고 생각하는가? --Redrose64 🌹 (토크) 13:48, 2017년 5월 7일 (UTC)

WP:BRINT도 항법 페이지의 일종이다. -- Pankaj Jain Capankajsmilyo (talk · concernes · count) 14:02, 2017년 5월 7일 (UTC)

페이지 말고 네비게이션 템플리트라고 써 있어.항해 템플릿은 이와 같은 것이다. --Redrose64 🌹 (대화) 15:30, 2017년 5월 7일 (UTC)

구체적으로 무엇을 말하는 겁니까?Redrose가 위에서 말한 것과 달리, WP에서는 [[대상 리디렉션]에서 [[간접]]로 링크를 변경할 수 있다.중단되지 않음(일반적으로 선호됨)컨텍스트가 유지되는 한 [redirect]에서 [target]로 링크를 변경할 수도 있다.WP에 의거하지 않을 수 있는 사항:UNBRANN은 [[재연결]을 [[대상 리디렉션]으로 변경한다.—파릭스 (tc) 10:55, 2017년 5월 8일 (UTC)

구체적으로 지수에 대한 [[대상]의 링크, 특히 자이나주의 지수에 대한 링크를 변경할 것을 제안한다. -- Pankaj Jain Capankajsmilyo (talk · 기여 · 카운트) 12:26, 2017년 5월 8일 (UTC)

너는 내가 쓴 것을 오해했다.의 사용을 지지한다.[[redirect]]메인 스페이스 페이지에, 그리고 그것을 로 바꾸는 것에 반대한다.[[target redirect]] 탐색 템플릿은 제외. --Redrose64 🌹 (대화) 11:11, 2017년 5월 8일 (UTC)

우리가 이것을 내비게이션 박스에 고정하는 이유는 링크된 페이지의 thgat이 중요한 것이다. 즉, 그것은 사용자 경험에 영향을 미친다.이것을 인덱스에 고정하는 것은 링크된 페이지들 중 어떤 페이지에서도 초월되지 않기 때문에 이 결과를 가지고 있지 않다.עודדהוodOd Mishehu 19:46, 2017년 5월 10일 (UTC)

카테고리에 레이블이 추가되지 않았는데, 목록에 레이블이 있어야 하는 이유는?추가 라벨링이 제공하는 가치는 무엇인가? -- Pankaj Jain Capankajsmilyo (talk · 기여 · 카운트) 20:16, 2017년 5월 15일 (UTC)

테크 뉴스: 2017-20

21:48, 2017년 5월 15일 (UTC)

mw.util.addPortletLink의 스크립트 이후 문제

최근의 대본 이후 나는 모든 필요한 변화를 시도했고 모든 것이 다시 작동하고 있었지만, 며칠 전 나의 대본들 중 일부는 다시 작동을 멈췄다.몇 가지 테스트 후에, 나는 mw.util.addPortletLink의 통화에 대한 코멘트가 문제를 해결한 것을 보았다.또 이런 일에 부딪힌 사람이 있나?스티비가 그 남자! 2017년 5월 13일 19:06 (UTC)

브라우저 콘솔에 있는 내용러슬릭_제로12:24, 2017년 5월 15일 (UTC)

@Stevietheman: 위키백과의 첫 번째 섹션을 참조하십시오.Billage_pump_(기술)/Archive_154#Old_script-procript-pecalypse, 특히 mw.util.addPortletlink()를 어떻게 사용해야 하는지 vs, 얼마나 많은 사람이 사용하고 있는지.—DJ (대화 • 기여) 13:07, 2017년 5월 15일 (UTC)

고마워. 내가 관련 조언을 실행했는데, 이제 모든 것이 잘 되고 있어.재미있는 것은 대략 5월 11일까지 mw.util.addPortletLink 전화에 문제가 없었다는 것이다.스티비가 그 남자!^{Talk • Work} 2017년 5월 15일 16:25 (UTC)

@Stevietheman:아래 새로 추가된 § Tech News: 2017-20을 참조하십시오. mediawiki.util 지난 며칠 동안 기본 JS 환경에 자동 로드된 상태였습니다.공식적으로, 이 실 제목은 레이저 프린터와 관련된 끔찍한 재난을 생각나게 한다.머프9000 (대화) 02:55, 2017년 5월 16일 (UTC)

인포박스위치

나는 지난 주에 일어난 것 같은 변화를 알아차렸다.안드로이드 앱 사용자인 내게 인포박스는 내가 하이퍼링크를 누르면 나타나는 기사 예고편을 빈칸으로 렌더링하는 리드 단락 대신 모든 기사의 시작 부분에 등장하기 시작했다.무슨 일이 있었는지 누가 말해줄래?에 대해 언급해 주시오.{{ping}}답장할 경우 템플릿.• 새미 마지드 • 대화 • 창작 • 위키백과 아랍어 • 15:56, 2017년 5월 13일(UTC)

사용자:DBRANT(WMF)는 아마도 질문에 대한 답을 알고 있을 것이다.Whatamidoing (WMF) (토크) 15:31, 2017년 5월 15일 (UTC

안녕 @SammyMajed:, 이것은 사실 mobileview API의 최근 업데이트로 인한 서버측 문제였다.문제가 해결되었고, 모든 캐시가 업데이트 된 것 같다.이 문제는 https://phabricator.wikimedia.org/T165119에서 추적되었다.아직도 그런 일이 일어나고 있는지 우리에게 알려줘.DBrant (WMF)(대화) 20:00, 2017년 5월 15일 (UTC)

@DBRANT (WMF): 답장 고마워.이 문제는 대부분의 기사에서 해결되었지만, 아이젠하워 달러와 같은 일부는 남아 있다.• Sammy Majed • Talk • Creation • 위키백과 아랍어 • 04:25, 2017년 5월 16일 (UTC)

감시 목록이 로드되지 않음

어제부터 나의 워치리스트는 로딩을 중지했다.내가 문제 삼고 있는 유일한 위키피디아 페이지야.때때로 그것은 "이 페이지는 작동하지 않는다.en.wikipedia.org은 현재 이 요청을 처리할 수 없다.HTTP ERROR 500."내 기본 설정의 최신 옵션뿐만 아니라 모든 변경 사항을 표시하기 위해 Expand watchlist(감시 목록 확장)를 비활성화하면 로드되지만 이상적이지 않다.브라우저:크롬 버전 58.0.3029.110. --1337 게이머(대화) 06:21, 2017년 5월 16일(UTC)

직립

글로벌(모든 Wiki에 대한 의미)에서 "일반적인" 2010 벡터 편집기 도구 모음에 해당하는 도구로 이미지를 삽입하는 "올라이트" 옵션을 추가하는 것이 타당하지 않을까?이 기능은 실제로 그리 드물지 않게 사용되기 때문에 디폴트 기능이 꽤 유용할 것 같다.당신의 견해는?--휴본 (대화) 07:12, 2017년 5월 16일 (UTC)

백스페이스 후 문자 삽입 시 크롬 문제

이게 브라우저 문제인지 위키피디아 문제인지는 모르겠지만 크롬에서만 발생한다.편집 시 문제가 발생한다.만약 내가 백스페이스로 문자를 제거한 다음 위키피디아의 '삽입' 도구 모음을 사용하여 대체 문자를 삽입하면, 새로운 문자가 잘못된 위치에 삽입된다. 마우스 포인터가 있는 위치가 아니라 다음 문자 뒤에 새 문자가 삽입된다.예를 들어, "에콰도리안-페루비아 전쟁"이라는 구절에서 나는 하이픈을 엔다쉬로 교체하고 싶어 백스페이스로 하이픈을 제거한 다음 툴바에서 엔다쉬를 클릭한다; 결과는 "에콰도리안-페루비아 전쟁"이 아니라 "에콰도리안P-에루비아 전쟁"이다.나는 파이어폭스, 엣지, 오페라에서 이것을 시도해 보았다. 문제는 발생하지 않았다.크롬밖에 없어.또 다른 참고: 포인터를 왼쪽에 놓고 Delete(삭제)를 눌러 원하지 않는 문자를 제거하면 문제가 없으며 올바른 위치에 대체 문자가 나타난다.식민지 크리스 (토크) 08:57, 2017년 5월 16일 (UTC)

MediaWiki 메시지/템플릿 혼동

IP 기여 페이지에서 MW 바닥글에 대해 알게 된 이슈를 파악하는데 운이 없다. MediaWiki:스프-공헌-발톱-아논.바닥글은 {{anontools}}}}을 복사하고, 템플릿의 WHOIS 링크는 tools.wmflabs.org/whois/gateway.py으로 호출된다.그러나 IP기여 페이지(예)의 바닥글은 최근 상대적으로 유용한 도구에서 거의 무용지물로 전락한 로브텍스 whois를 부르고 있다.아무리 null 편집이나 숙청해도 링크가 바뀌지 않았기 때문에, 필자는 필자가 잘못된 풋어 코드 같은 것을 보고 있는 것 같은 것을 놓치고 있는 것이 틀림없다고 판단했다.누군가가 나를 위해 이것을 좀 밝혀줄 수 있기를 바란다.고마워요.—DoRD (대화) 14:50, 2017년 5월 16일 (UTC)

@DoRD: IP 템플릿은 템플릿에서 가져오며,Anontools/ipv6 또는 템플릿:아논툴스/ipv4.ipv6 템플릿이 업데이트되었지만 ipv4 템플릿은 여전히 Robtex를 사용한다.샘 월튼 (대화) 14:55, 2017년 5월 16일 (UTC)

봐, 내가 뭔가 놓치고 있다고 말했어.MW 메시지 페이지는 여전히 나에게 다소 미스터리하지만, v4 템플릿을 업데이트하여 다시 유용하게 만들었다.고마워! —DoRD (대화) 15:01, 2017년 5월 16일 (UTC)

*헤드데스크* {{anontools}}}}의 출처를 조사했어야 했다.—DoRD (대화) 15:06, 2017년 5월 16일 (UTC)

제목 버그 표시?

샌프란시스코(sans-serif typeface) 페이지는 소문자 "san" ("san Francisco")로 제목을 렌더링하고 있는데, 왜 그런지 알 수 없다. 페이지에 디스플레이틀이 없다.이거 벌레야?이반벡터 (/)^Talk_Edits 14:12, 2017년 5월 16일 (UTC)

• 크롬과 IE에서 로그인한 경우와 로그아웃한 적이 있는 경우도 마찬가지다.그 이유 또한 알 수 없다.검은 연 (토크) 14:17, 2017년 5월 16일 (UTC)

변환된 템플릿에 포함된 noinclude 내부 {{lowercase title}을(를) 이동하여 고정.[33]프라임헌터 (토크) 14:21, 2017년 5월 16일 (UTC)

고마워! 잘했어.이반벡터 (/)^Talk_Edits 16:58, 2017년 5월 16일 (UTC)

이상한 파일 업로드 기록

파일:Aleta Ogord.jpg.가장 오래된 개정판은 업로드 기록의 맨 위에 표시되며, 파일 크기는 줄어든 반면, 파일 미리보기에는 더 오래되고 더 큰 이미지가 표시된다.clpo13_(talk) 17:20, 2017년 5월 16일(UTC)

파일:A.O.jpg는 원본 파일 버전이 삭제되었다가 나중에 복원되었음을 보여준다.파일 버전의 복원이 가장 최근의 파일 작업이라면 원래 업로드 순서에 상관없이 해당 버전이 최신 버전이 되는 것 같다.내 생각에 그 버전은 다시 삭제될 수 있을 것 같아.프라임헌터 (대화) 17:41, 2017년 5월 16일 (UTC)

완료. 벤첼라이트 17:50, 2017년 5월^Talk 16일 (UTC)

고마워! clpo13_(talk) 18:50, 2017년 5월 16일 (UTC)

STiki 세션 로그아웃

나는 5분 동안 두 번이나 Stiki에서 로그아웃을 당했고 15분 후에 다시 Stiki를 발사했다.에러메세지는 그것이 나의 문제나 STiki의 문제가 아니라고 말한다.다른 고통받는 사람은 없으십니까? 예: L3X1 (distant writer) 03:00, 2017년 5월 16일 (U)

@L3X1: STiki란 무엇인가?정확한 오류 메시지는 무엇인가?이것이 영어 위키백과와 어떤 관련이 있는가?어떻게 하면 문제를 줄일 수 있을까? --말야코 (대화) 11:18, 2017년 5월 16일 (UTC)

WP:STiki를 참조하십시오. --Redrose64 🌹 (토크) 11:29, 2017년 5월 16일 (UTC)

그럼 이건 그냥 내 문제야?Stiki를 다시 불을 지폈지만 아무런 문제가 없었다. 예: L3X1 (distant write) 19:48, 2017년 5월 16일 (UTC)

<<cite> vs. <스판>과 인쇄된 URL.

2015년 9월 26일 이전, cs1 2 템플릿(templates){{cite book}},{{citation}}, ...) 산출물은 로 포장되어 있었다.<span>...</span>가지고 있던 태그class=그리고id=특성그 날짜에 포장지가 로 바뀌었다.<cite>...</cite>태그는 해당 태그 내용의 강제 기울임꼴화가 제거되었기 때문에 그리고<cite>...</cite>더 의미론적으로 옳다.우리가 분명히 알아차리지 못한 것은 cs1 2 인용문이 인쇄 가능한 버전의 기사 URL을 잃어버렸다는 것이다.

여기 세 가지 예가 있다.

1. 견문이나 인용 부호를 사용하지 않고.
2. 스팬 태그가 있는
3. with cite tags

왼쪽 사이드바의 인쇄/내보내기 메뉴에서 인쇄 가능 버전을 클릭하면 다음과 같은 내용이 표시됨:

1. span 또는 인용 태그 미포함(http://www.example.com)

2. 스팬 태그 포함(http://www.example.com)

3. 인용 태그가 있는

인쇄 가능한 버전의 페이지 소스를 보면 다음이 표시됨:

<>li>, <rel="nofollow"class="외부 문자"href="http://www.example.com">without범위 또는을 인용하 tags<, /a>,<>/li>,<>li>,<>span>,<>;rel="nofollow"class="external textᆮhttp://www.example.com">with기간 tags<, /a>,<>/span>,<>/li>,<>li>,<>cite>, <rel="nofollow"class="외부 문자"href=."http://www.example.com">with를 인용하다 tags<, /a>,<>/cite>,<>/li>.

브라우저 문제라는 뜻인가?html 이슈?css 문제?미디어위키 문제?다른거?

나는 온라인 버전에서 제목 텍스트 뒤에 숨겨진 URL을 보여주는 것이 인쇄된 기사 페이지에 중요하다고 생각한다.

—스승 (대화) 11시 40분, 2017년 5월 16일 (UTC)

HTML5의 인용 태그에 따르면, 인용은 아닌 작품 제목에 대한 것이다.그래서 나는 그것이 의미론적으로 옳다고 확신할 수 없다.러슬릭_제로 12:06, 2017년 5월 16일 (UTC)

역사에 관심이 있는 사람들은 미디어위키에서 이 토론을 보고 cs1 2에서 이 토론을 보라.

—스승(대화) 12:19, 2017년 5월 16일 (UTC)

고쳤어. 왜 거기 있었는지 잘 모르겠어. 그때(2010년 이전)에는 기록되어 있지 않았으니까.이 변경으로 인해 문제가 발견되면 ping해줘.—DJ (대화 • 기여) 12:33, 2017년 5월 16일 (UTC)

좋아, 고마워

—스승(대화) 12:56, 2017년 5월 16일 (UTC)

@Ruslik0:3개 학교에서 읽는 모든 것을 믿지 마라.요소에 대한 HTML5 스펙을 확인하면, 해당 요소가 창작물에 대한 참조를 나타낸다고 되어 있다.그것은., 그래서 어느 것 적어도 하나(어디에 실현 가능한)의 포함된다 우리의 사용, 유효합니다.--Redrose64(이야기), 5월 16일 2017년(CoordinatedUniversalTime)20:26 🌹 그 일의 간략한 형식에 관습은 표창 메타 데이터의 추가에 사용된 대롤 수 있는 제목 또는 author(사람, 사람들 또는 조직)의 이름이나 URL참조를 포함해야 한다.

기사 링크와 관련될 때 사용되는 파이핑 링크 목록을 가져오시겠습니까?

[[Topic A Name A]]와 같은 pip 링크가 주어졌을 때, "Topic A"의 링크와 함께 사용되는 "Name A"의 다양한 용도의 목록을 얻을 수 있는가?AWB 마법을 쓸 수 있을 것 같은데 온위키 방법이 있는지 궁금하다.

내가 이것을 원하는 구체적인 사례는 비디오 게임이다: 온라인 연결이 필요한 게임에 관한 기사의 경우, 일부 편집자들은 온라인에서 약간 POV 푸싱이 될 수 있는 "온라인"이라는 피핑된 텍스트와 Always-on DRM(디지털 권한 관리)과 연계되어 있다 - DRM은 일반적으로 논란이 되고 있으며, 단지 게임이 온라인 전용이라는 이유만으로 보여진다.DRM을 제어하려는 것이 아니라, 플레이어들은 종종 DRM을 그렇게 잘못 보고 있다.이 특정 [[Always-on DRM online] piped 링크가 사용되고 있는 사례를 검토하고자 한다. --MASEM (t) 00:45, 2017년 5월 17일 (UTC)

정확히 그것을 말하는 사람은 없다.모든 파이핑된 링크를 검색하는 데 더 관심이 있을 수 있음: linksto:"상시(Always-on) DRM" 소스:/\[Always-on(Always-on) DRM\ /i.mw: 참조도움말:CirrusSearch#Insource.프라임헌터 (대화) 01:12, 2017년 5월 17일 (UTC)

WikiProject 배너에서 "가져오기" 매개 변수 제거

나는 내가 관여하고 있는 위키프로젝트가 배너에 있는 "중요" 매개변수를 사용하여 중단되어야 한다고 제안할 계획이다.프로젝트 관리에 있어 실질적인 가치가 거의 없거나 전혀 없고, 등급이 전적으로 주관적이며, 낮은 등급이 기사 주제에 대한 모욕이라고 느끼는 사람들이 있기 때문에 불행과 심지어 싸움으로 이어진다.배너나 프로젝트의 기사 평가표에 더 이상 표시되지 않도록 파라미터를 실제로 제거/끄는 것이 가능한가?로저 (Dodger67) (대화) 16:50, 2017년 5월 16일 (UTC)

일부 프로젝트에서는 "가져오기" 매개 변수(@Iridescent: Echo를 사용하도록 설정했다고는 생각되지 않지만 이에 대해 질문할 사람이 될 수 있음)가 있지만, 템플릿에는 현재 어떤 기능도 없다고 생각한다.WPBannerMeta를 사용하여 해당 매개 변수를 끄십시오.하지만 내 생각에 중요도 등급은 대개 무의미하다.조조 유메루스 (토크, 기여) 16:59, 2017년 5월 16일 (UTC)

위키프로젝트 비주얼 아트는 아마도 중요도 규모를 포기하는 가장 주목받는 프로젝트일 것이다.AFAIK, 실무에서 당신이 해야 할 일은 더 이상 중요 범주가 표시되지 않도록, 그리고 Category:저임시성 foo 기사 등이 더 이상 채워지지 않도록 토크 페이지 배너 템플릿을 바꾸는 것이다. 그러면 봇은 돌아가면서 여유롭게 시청률을 제거할 수 있다.∙ 무지개빛 17:03, 2017년 5월 16일 (UTC)

문제의 템플릿 설정 방법에 따라 이 변경만 하면 될 것 같다.- 이리슨트 17:07, 2017년 5월 16일(UTC)

고마워, 이제 프로젝트 구성원들의 합의만 있으면 돼.로저 (Dodger67) (대화) 17:37, 2017년 5월 16일 (UTC)

@Dodger67 및 Iridescent:그 변화는 그렇게 되지 않을 것이다, 왜냐하면 IMPORTANCE_SCALE=no와 같은 대우를 받다 IMPORTANCE_SCALE=yes또는 IMPORTANCE_SCALE=standard; 물리적으로 파라미터를 제거하더라도 간단히 마치 IMPORTANCE_SCALE=standard(기본값)이 존재했다. 왜하하면 되기 때문이다.{{WPBannerMeta/importance}}다음 두 가지 값만 인식:inline그리고subpage- 다음을 포함한 다른 모든 것no그리고 결석은 로 취급된다.standard시키려면 . 요도도 remove도 된다 importance={{{importance }}}매개 변수제거 중 IMPORTANCE_SCALE=매개변수(있는 경우)도 수행될 수 있지만 필수적인 것은 아니다.

향후 참조를 위해 템플릿 토크에 이러한 성격의 질문이 게시될 수 있다.나나 MSGJ(토크·컴퍼니) 등 위키프로젝트 배너 시공 전문가들이 조언을 해주는 WPBannerMeta. --Redros64 🌹 (토크) 20:05, 2017년 5월 16일 (UTC)

Redros64 수정해줘서 고마워.로저 (Dodger67) (토크) 07:09, 2017년 5월 17일 (UTC)

사용자:Bethro/common.js

누가 나에게 이것을 설명해 줄 수 있니?보아하니...보통 사용하는 대본에 비하면 엄청나다.나는 WP의 어떤 종류라고 추측했다."NOTREPOSITIORATIORY 같은 것은 아니지만, 가능하다면 좀 더 깊은 이해를 하고 싶다.건배! — O Fortuna ^{semper crescis, aut decrescis} 06:26, 2017년 5월 17일 (UTC)

@Fortuna Imperatrix Mundi:코드를 이해하기 시작할 수는 없지만, 포함된 메시지들은 스크립트가 현재 기사에 대해 일종의 가독성 지수를 계산하고 있음을 시사한다. -- John of Reading (토크) 07:49, 2017년 5월 17일 (UTC)

그래, 나도 동의해. 사용자:베슬로/공통.css.몇 개의 새로운 전화선이 틀리지 않을 것이다.누가 베슬로(토크·컴퍼니)에게 이것들이 어디서 왔는지 물어본 적 있어? --Redrose64 🌹 (토크) 09:08, 2017년 5월 17일 (UTC)

읽기에는 끔찍하지만 페이지뷰마다 브라우저로 다운로드하면 효율적이게 만드는 "민간화"가 되었다.위키피디아와 직접 관련이 있는 것처럼 보이므로 "WP는 …이 아니다" 유형의 문제는 없어야 한다.위에 제시된 바와 같이 어떤 종류의 기사 품질 분석은 합리적인 내기처럼 보인다.상당히 진보된 JS & CSS에 들른 것은 첫 편집으로서 상당히 이례적인 일이다.내가 그것에 대해 당장 우려하는 유일한 것은 저작권과 면허증이다.사용자 자신의 일이라면(그럴 수도 있고, 달리 제안할 만한 것을 발견하지 못했다) 문제될 것이 없다.그것은 새로운 계정에 대해 신뢰할 수 없는 것처럼 보일 수도 있지만, 그들은 IP 사용자로서 이 스크립트를 사용하고 개발했을 수도 있다(Greasemonkey 등을 사용하여 WP 페이지 뷰에 삽입).어디선가 베끼면 면허증도 없고 귀인도 부족하다.Murph9000 (대화) 11:58, 2017년 5월 17일 (UTC)

위키피디아의 키워드 검색은 그것을 개발하는 데 역할이 있었던 것으로 보이는 또 다른 계정과 설명 페이지를 불러온다.이름만 대면 다른 사람에게 맡기지 않겠다 - 관리자 입장에서 보면 추구할 가치가 없어 보인다. -- zzuzz 12:18, 2017년 5월 17일 (UTC)

• @Fortuna Imperatrix Mundi:좋아, 약간의 탐정 작업을 해보니, MIT 면허가 있는 Quality Assisted Editor인 것 같다. (저작권과 라이센싱에 관한 한 괜찮아야 한다고 생각한다.그 도구의 현재 상태가 어떤지 모르겠다(WMF와 함께 사용하거나 EN-WP에서 사용).나는 CSS & JS를 지역 개인 CSS & JS로 직접 복사하기 보다는 tools.wmflabs.org에서 로딩하는 것을 추천할 것 같아.또는, 그것에 대한 수요가 있고 도구가 합리적인 실사를 통과한다면, 그것들은 기기로 추가될 수 있다.Murph9000 (대화) 12시 20분, 2017년 5월 17일 (UTC)

@Reading의 John, Redros64, Murph9000, Zzuzz:이 일을 도와주셔서 모두 감사하다.그것은 모두 나와는 거리가 멀지만, 그 무해함에 대해 확신한다면, 나는 안심할 수 있다.조심해, 모든 것이 꽤 흥미로워 보여.고마워! — O Fortuna ^{semper crescis, aut decrescis} 12:25, 2017년 5월 17일 (UTC)

관리자가 합리적으로 귀속(페이지 기록 또는 페이지 속성 중 하나)을 추가할 수 있는 것은 MIT 라이선스에 필요한 것으로 추측하기 때문이다. (대화 페이지에서 할 수 있을 것 같음.) --Izno (대화) 2017년 5월 17일 (UTC)

만약 그곳에 우려가 있다면, 그것은 이루어질 수 있다.내 자신의 비공식적인 의견은 MIT 라이센스 파일이 라이센스 헤더/코멘트 없이 홈 위치에서 배포될 때(여기서 볼 수 있듯이) 저작권 소유자에 의해 그러한 의무는 암묵적으로 면제된다는 것이다.WP가 그것에 대해 더 강한 견해를 갖고 싶다면, 그것도 괜찮다.Murph9000 (대화) 12:41, 2017년 5월 17일 (UTC)

모바일의 카테고리

안녕, 나는 카테고리를 로드하여 모바일 인터페이스 페이지에 추가하는 간단한 가젯을 만들었어.기본 설정 섹션의 가젯에서 테스트할 수 있다.만약 사람들이 이것이 바람직하다고 생각한다면, 가젯이 디폴트로 설정될 수 있다(모든 사람을 위해 또는 일부 특정 사용자 그룹에 대해서만).—DJ (대화 • 기여) 13:37, 2017년 5월 17일 (UTC)

파일 업로드 마법사가 실패함 - js와 관련된 내용?

나는 위키피디아를 사용하려고 한다:파일 업로드 마법사 그러나 "업로드 마법사를 시작하려면 여기를 클릭하십시오"를 클릭해도 아무 일도 일어나지 않음.생각나는 거 있어?

나는 그것이 끝이라는 것을 안다.JS 그래서 나는 그것이 자바스크립트라고 생각한다.나만의 자바스크립트 파일이 작동하지 않는 것 같아서 따로 알아봤는데 관련이 있을 것 같아.어떤 문제에 관한 트래픽은 어렴풋이 기억하지만 어디서부터 시작할지, 어떻게 해결할지 기억이 나지 않는다.--S 필브릭(Talk) 13:45, 2017년 5월 17일 (UTC)

@스필브릭:Javascript 페이지에 항목을 추가할 때는 해당 항목을 유지 관리하십시오.귀찮게 하는 것은 아니지만, 당신이 위키피디아를 실제로 사용할 수 있었다는 것이 놀랍다.Js의 변화, monobook.js의 변화, 벡터.js의 변화, 내가 해야만 했던 모든 공통점을 가지고 있다.그 안에 무엇이 있는지 이해하지 못하면 위험하고 여러 가지 물건을 깨뜨릴 수 있다.가능한 경우 가젯을 사용해 보십시오.무엇을 하고 있는지 모를 때 제거/기억울하십시오.—DJ (대화 • 기여) 14:26, 2017년 5월 17일 (UTC)

파일 업로드 마법사가 내 모노 북 페이지와 무슨 관련이 있는가?그럴지도 모르지만 파일 업로드 마법사를 만들지 않았으니 왜 내 일반적인 JS 파일의 오류가 그 파일과 관련이 있는지 이해할 수 없다.--S Philbrick(Talk) 14:29, 2017년 5월 17일 (UTC)

업로드 마법사가 다시 작동하고 있는 것 같은데, 고마워.기술적 무지는 유감이지만, 왜 내 .js 파일의 어떤 것이 수천 명의 편집자가 사용한 것으로 추정되는 다른 사람이 만든 마법사에 영향을 미치는가?--S Philbrick (Talk) 14:35, 2017년 5월 17일 (UTC)

왜냐하면 그 모든 코드는 동일한 브라우저 창 안에서 실행되기 때문이다.만약 한 가지가 고장 나면, 동시에 달리도록 되어 있는 다른 모든 것들을 방해할 수 있다.—DJ (대화 • 기여) 14:40, 2017년 5월 17일 (UTC)

이제 미디어위키를 확장해야 할 때인 것 같다.Jswarning, 가능하다면 Gadgets를 사용하고 Javascript가 무엇인지 이해할 수 있는 조언과 함께...—DJ (대화 • 기여) 14:40, 2017년 5월 17일 (UTC)

모든 페이지(또는 대부분의)가 단순한 텍스트로 구성되는 것은 인터넷(또는 최소한 html)의 고유한 결함(또는 기능)이다.이것은 브라우저, Javascript, 브라우저 확장, 그리고 심지어 운영 체제도 브라우저에서 당신이 받는 거의 모든 것을 쉽게 망칠 수 있다는 것을 의미한다.웹 개발을 토종 OS 애플리케이션과 비교해 악몽으로 만드는 것이다.이 경우 충분히 이해하지 못한 채 javascript를 사용할 때마다 "속성" 렌더링이나 디스플레이를 방지하는 스크립트 오류를 쉽게 발생시킬 수 있다는 것을 의미한다.실제로 웹사이트에 보고된 많은 오류는 실제로 외부 요인(예: 사용자첨자, 확장자, 네트워크 연결 또는 ISP)에 의해 발생한다.

독자들이 단지 자바스크립트를 무력화시키고 이러한 문제의 90%에서 벗어날 수 있다는 것은 다행스러운 일이지만, 그들 중 +90%는 아마도 그런 스위치가 존재하는지 혹은 그것이 무엇을 하는지조차 모르고 있을 것이다.— 197.218.88.223 (대화) 15:02, 2017년 5월 17일 (UTC)에 의해 추가된 선행 미서명 의견

빅 블루 버튼을 누르면 스크립트가 중단됨

나는 mw:에서 몇 가지 정보를 수집했다.OOjs UI/Fixing 스크립트 및 "Save" 버튼(및 근처에 있는 다른 버튼)의 변경에 대한 가젯.이는 단순한 색상의 변화가 아닌 기술적인 변화로, 불행하게도 여러 편집 관련 스크립트를 깨트릴 것으로 보인다.스크립트를 유지 관리하는 경우 해당 페이지를 확인하고 스크립트(페이지의 지침)를 테스트하십시오.Whatamidoing (WMF) (토크) 19:20, 2017년 5월 17일 (UTC)

사이드바에서 링크 변경

의 사이드바에서 링크를 변경하는 데 문제가 있다.wikisource(연결할 의향이 있는 wikisource)는:s:Hjalp:Efnisyfirlit.몇 년 전에 나는 도움말 링크를 변경했다.위키피디아는 그렇게 했지만, Ruslik이 같은 일을 했을 때는.내가 그에게 그렇게 해달라고 부탁한 후 위키소스는 작동하지 않았다.내가 변화라고 말한지 몇 년이 지났지만 당연하다.위키피디아 하지만 난 아직도 이것에 대해 어리둥절해.사이드바의 링크는 다른 방식으로 변경되어야 하는가?왜 위의 변화는 연결되어 있는가?위키소스가 작동하지 않는가? --Snaevar (대화) 18:32, 2017년 5월 17일 (UTC)

이제 효과가 있는 것 같다.내 경험상 미디어위키 네임스페이스에 대한 변경사항이 적용되기 전에 지연될 수 있다.프라임헌터 (대화) 21:35, 2017년 5월 17일 (UTC)

이메일 반송 페이지

현재 '이 사용자 이메일 보내기' 기능을 통해 이메일을 보내면 완료 시 '사용자에게 돌아가기:예' (혹은 기괴하게도 메인 페이지로!- 나는 항상 '당신이 있던 곳으로 돌아가라'는 것이 가장 합리적일 것이라고 생각해 왔다.같은 본문에도 {{ygm}} 등을 이용해 e-메일이 있다는 사실을 알릴 수 있다는 점을 지적하고 있기 때문에 '사용자 대화로 돌아가기:예'?내 말은, ygm 공지를 남기거나 말거나 둘 중 하나야.만약 그렇다면, 여러분은 그렇게 하기 위해 토크 페이지에 올라가고 싶어한다.만약 그렇지 않다면, 어떤 페이지를 추천하든 상관없어!— O Fortuna ^{semper crescis, aut decrescis} 13:45, 2017년 5월 16일 (UTC)

메인 페이지로 간다는 게 무슨 뜻인지 모르겠어.'사용자에게 돌아가기:' 옵션만 표시됨:예' 입니다.사용자 공간에서 "이 사용자에게 전자 메일 보내기"를 누른 위치에 관계없이 사용자 페이지에 연결됨.그것은 "복귀"라고 말하는 링크치고는 좀 이상하게 보일지도 모른다."토크 페이지 메시지를 남겨서 이메일을 보냈다는 것을 사용자에게 알릴 수 있다. {{You've got mail} 템플릿은 이를 위해 사용 가능하다."는 영어 위키백과의 미디어위키:이메일 텍스트 사용자 정의로 제작되었다.MediaWiki 기본값은 "전자 메일 메시지가 전송됨"이라고만 표시됨.사용자 이름은 MediaWiki:Emailsenttext에서 매개 변수로 사용할 수 없으며 Special:EmailUser를 사용할 수 없도록 하기 위한 시점{{PAGENAME}}또는 사용자 이름 검색과 유사함."사용자에게 돌아가기:예"는 아마도 MediaWiki에 의해 만들어졌을 것이다.다른 많은 곳에서 사용되는 반환점.내 결론은:MediaWiki 디폴트는 사용자 토크 페이지를 링크할 특별한 이유가 없으며, 나는 현재 MediaWiki:Emailsenttext의 호출에 사용자 이름이 포함된 1달러 매개 변수와 같은 MediaWiki 소프트웨어의 변경 없이 영어 위키백과에서 할 수 있는 방법이 보이지 않는다.사용자 정의된 MediaWiki:Returnto는 그것이 Special에 있는지 탐지할 수 있다.EmailUser를 추가하고 사용자 대화 링크를 추가하지만 $1을 분석하여 사용자 이름을 검색하거나 링크를 조작할 수 있는 액세스 권한이 있는지 잘 모르겠다.그리고 그것은 어쨌든 사소한 문제로, 아마도 MediaWiki 사용자 정의에 따른 성능 비용으로는 가치가 없을 것이다.파서 함수를 사용하여 반환하십시오.프라임헌터 (토크) 14:15, 2017년 5월 16일 (UTC)

그 철저한 분석에 감사한다, 프라임팩. 언젠가 메인 페이지로 갈 수 있을 거라고 맹세할 수 있었다.신경쓰지 마세요.어쨌거나, 그럼 우리 손 밖이라고 생각하나? 답신 페이지를 어디로 보내야 할지?아, 정말 부끄럽다.BTW는 코드를 바꾸는 데 1달러가 든다는 뜻이었습니까? 아니면 그 코드 조각이 바뀐다는 말이었습니까?— O Fortuna ^{semper crescis, aut decrescis} 14:24, 2017년 5월 16일 (UTC)

잘못된 프라임 ;) 프라임팩 (대화) 14:25, 2017년 5월 16일 (UTC)

@PrimeHunter and Primefac: 미안한데 ...! - 내가 처리하기에는 너무 많은 프라임!;) — O Fortuna ^{semper crescis, aut decrescis} 14:43, 2017년 5월 16일 (UTC)

$1, $2, ...는 MediaWiki가 이름 없는 템플릿 매개 변수에 대해 호출자의 액세스 매개 변수를 {{{1}, {{{2}}}}와 유사한 방법으로 메시지 전송하는 방법이다.예를 들어 MediaWiki:리턴토는 "1달러로 돌아가라"고 말하는데, 여기서 1달러는 미디어위키 소프트웨어가 메시지를 호출할 때 주는 값이다.문제는 MediaWiki:Emailsenttext가 호출에서 사용자 이름을 $1 매개 변수로 얻지 못한다는 점이다(어쨌든 내가 알기로는 https://translatewiki.net/wiki/MediaWiki:Emailsenttext/qqq이 매개 변수를 확인하는 정상적인 방법일 텐데 translatewiki.net이 나를 위해 응답하지 않는 것으로 알고 있다.우리는 그것을 로컬로 추가할 수 없지만, 그것을 추가하기 위해 일반적인 MediaWiki의 변경이 phab에서 요청될 수 있다.프라임헌터 (대화) 14:35, 2017년 5월 16일 (UTC)

자세한 설명 정말 고마워!고마워— O Fortuna ^{semper crescis, aut decrescis} 14:44, 2017년 5월 16일 (UTC)

Fortuna Imperatrix Mundi는 $1#다른 용도와 $sign#컴퓨터 소프트웨어에서 사용; 그것은 더 광범위한 컴퓨터 과학 용도를 참조하십시오.Nyttend 백업(대화) 12:17, 2017년 5월 17일(UTC)

고마워, 니튼:quid만 내면 되는 그것의 유사성은 약간은 있음직하지 않다는 것을 알았어야 했다!— O Fortuna ^{semper crescis, aut decrescis} 12:22, 2017년 5월 17일 (UTC)

아마존닷컴이 드디어 대응하고 있다.놀랍게도 https://translatewiki.net/wiki/MediaWiki:Emailsenttext/qqq은 "1달러 - (선택사항) 로컬 사용자 지정에 대한 수신인의 사용자 이름"이라고 말한다.여전히 'Return to User:예' 그러나 사용자 대화 링크를 MediaWiki:Emailsenttext에 추가할 수 있다.{{}}}}을(를) 사용하기 위한 프리로드 링크를 포함하여 이렇게 했다.[34] 직접 우편으로 발송한 후 작동하는 것을 시험해 보았다.프라임헌터 (대화) 11시 35분, 2017년 5월 18일 (UTC)

#절대:모바일 위키피디아에서는 차트가 형편없어 보인다.

제발 도와줘!기사 하단의 차트는 모바일 위키피디아에서 완전히 형편없어 보인다. https://bg.m.wikipedia.org/wiki/%D0%A4%D1%80%D0%B0%D0%B9%D0%B1%D1%83%D1%80%D0%B3

동일한 내용: https://en.m.wikipedia.org/w/index.php?title=Jeremy_Corbyn&oldid=731595817#Growth_in_the_Labour_Party

고마워! имрр янооо(토크 • 기여) 09:04, 2017년 5월 17일 (UTC)

첫 번째는 bg:фрарарарарарарарорарарарарарарарарарарарарарарара рарарарарарарарара рарарарарарарарарарарарарар

2
0
1
5

수평이 아니라동봉하는 것<div>...</div>원소에는 a가 있다.style=선언문을 포함하는 속성max-width:1px;(불가리아어) 또는max-width:2px;내가 꽤 확신하는 것이 직접적인 원인이다.또한 나쁜 CSS 선언이 있다.veritical-align:top;같은 속성으로, 무효가 되면, 이것은 무시될 것이다.나는 루아 전문가는 아니지만, 모듈 검색: 그 철자 실수를 위한 공간은 "정치적"이라는 것을 암시한다.drawXlegends모듈의 기능:차트는 시작하기에 좋은 장소일 것이다. --Redrose64 🌹 (토크) 09:23, 2017년 5월 17일 (UTC

코빈 사례는 르완들랜드가 모듈 토크에서 다음과 같이 보고했다.차트#모바일 위키백과 막대 차트 프리젠테이션은 도움 없이 끔찍하다.모듈:차트는 범례 x에 대한 최대 너비를 계산한다.그것은 분명히 표시된 열의 대략 너비로 되어 있다.내 Firefox에서 최대 너비는 데스크톱에서는 무시되지만 모바일에서는 따라와야 열이 좁을 때 텍스트가 수직이 될 수 있다.열이 많으면 최대 너비가 음수가 되고 데스크톱과 모바일에서 모두 무시된다.모듈에서 마지막 예에 대해 수행되는 경우:차트#최대 너비:-4px로 그룹별로 스케일 조정하여 모바일에서 보기에도 괜찮다.1960년 이전에 동일한 예가 끊어진 경우 최대 너비:6px의 양수를 얻을 수 있으며 모바일은 여기서 나를 위해 수직 텍스트를 표시한다.

최대 너비를 열 너비로 설정하는 아이디어는 각 열에 범례가 있고 열 너비에 맞지 않으면 수직으로 되거나 다음 범례와 마주친다는 것이어야 한다.그러나 위의 예와 같은 전설이 없는 컬럼이 많다면 최대 너비는 필요하지 않다.모듈이 자동으로 이것을 결정할 수 없다면, 나는 최대 폭을 생략하는 선택적 파라미터가 있어야 한다고 생각한다.만약 우리가 데스크톱에서 최대 너비를 적용하도록 모듈을 코드화하려고 한다면, 나는 우리의 차트의 많은 부분이 갑자기 모바일 외에도 데스크톱에서 불필요한 수직 레전드를 얻게 될 것이라고 생각한다.프라임헌터 (대화) 11:36, 2017년 5월 17일 (UTC)

고마워! 모듈 395호선에서 최대 너비-1px로 바꿨어.차트(불가리아어 위키백과에서).이제 모바일은 괜찮다(bg: 참조):фрарарарарорарарарарора ра ра ра ра ра ра урара) 그리고 나는 지금으로서는 데스크탑에서 어떠한 문제도 마주칠 수 없다.간단한 아이디어: 모듈 어딘가에 CSS 워드브레이크:keep-all을 추가할 수 있는가?차트? --дрр янооо(토크) 10:38, 2017년 5월 18일 (UTC)

@Димитър Янков:라는 이유max-width:-1px"작업"은 해당 속성에 대한 부정적인 값이 불법이기 때문에 브라우저가 선언을 무시하는 것이다.다른 브라우저의 경우는 그렇지 않을 수 있으므로 선언문을 완전히 삭제하는 것이 안전하다. --Redrose64 🌹 (토크) 16:00, 2017년 5월 18일 (UTC)

하위 페이지 이름만 가져오는 템플릿

템플릿과 유사:PAGNAME, 대신 하위 페이지 이름을 지정하십시오.예를 들어 제목이 Evanescence/The Open Door인 경우 The Open Door만을 제공한다.그런 템플릿이 있을까?—Lost Whischers 16_talk:48, 2017년 5월 18일 (UTC)

다음과 같은 마법의 단어가 있다.{{SUBPAGENAME}}. mw: 참조:도움말:매직_words#페이지_이름

—스승 (대화) 16:56, 2017년 5월 18일 (UTC)

고마워!—Lost Whischers 19:31, 2017년 5월 18일 (UTC)

또는 WP를 참조하십시오.VAR. --Redrose64 🌹 (토크) 19:41, 2017년 5월 18일 (UTC)

위키백과의 Wikidata infoobox 편집을 위한 프로토타입

여보세요

위키다타에게 가장 많이 요청되는 기능 중 하나는 위키다타의 데이터를 위키백과에서 직접 편집할 수 있도록 하여 편집자들이 웹사이트를 바꾸지 않고도 작업흐름을 계속할 수 있도록 하는 것이다.

Wikidata 개발팀은 이러한 목표를 달성하기 위한 도구를 개발해왔다: 위키백과에서 직접 위키백과에서 온 정보를 시각적 편집기를 통해 위키백과 인포박스에 채우고 편집하는 것이다.

우리는 이미 2015년에 피드백을 요청했고, 이 논문에서 여러분과 공유한 몇 가지 흥미로운 아이디어들을 수집했다.이 기능을 개선하고 지속적으로 개발하기 위해 당사의 첫 번째 프로토타입과 피드백을 수집하고자 한다.

우리는 이 작업을 매우 일찍 당신에게 제시하기 때문에 개발 전과 개발 전반에 걸쳐 당신의 피드백을 포함할 수 있다.귀하는 이 기능의 핵심 사용자이므로 귀하의 요구와 편집 프로세스에 맞는지 확인하십시오.

이 페이지에서 프로토타입, 특징 설명 및 데모 비디오를 찾을 수 있다.자유롭게 대화 페이지에 의견이나 피드백을 추가하십시오.그 페이지는 현재 모든 언어로 번역된 것은 아니지만, 번역하는 것을 도와서 당신의 기여를 추가할 수 있다.

Wikidata의 토크 페이지에 피드백을 추가하거나 여기에 코멘트를 추가할 수 있다.나는 당신의 모든 피드백을 고려하기 위해 이 논의를 따르겠다.그러나, 모든 사람들이 당신의 의견을 읽을 수 있도록 당신의 메시지를 중앙 위키다타 페이지에 쓰는 것이 더 나을 것이다.

고마워, Lea Lacroix (WMDE) (토크) 15:31, 2017년 5월 15일 (UTC)

안 돼, 안 돼!당신은 가장 중요한 부분 바로 앞에서 과감한 행동을 멈췄다."Visual Editor를 통해." enwiki에 대한 수동 편집의 95%는 VE가 아닌 표준 Wikitext 편집기에서 수행되는데, VE에 대해 요청된 기능만 릴리스(또는 적어도 먼저)하여 VE를 계속 추진하는 이유는 무엇인가?프람 (대화) 08:03, 2017년 5월 19일 (UTC)

그리고 물론, 이것은 URL을 소스로 사용하고자 할 때만 어느 정도 직관적으로 작동한다.예를 들어 책이나 신문 기사를 출처로 사용하고 싶을 때, 또는...Wikidata에서는 이것이 정말 쉽지 않기 때문에 당신은 곤경에 처하게 된다.그것은 소스가 없는 아이템이나 다른 위키에서 수입된 아이템, 혹은 제목이 짧고 그 이상도 없는 url sourecs를 중심으로 만들어진 것 같다.우리가 익숙한 수준에서 언급하는 것은?나는 소싱된 것으로 추정되는 아이템을 얻는데, 출처는 "위키다타에서 수입된 것" 예시라고 한다.나는 "nlwiki에서 수입된 것" 등이 서투른 사례라고 생각했지만, 이것은 정말 짜증나는 일이다.기본적으로, 당신은 수 년 동안 유지되어 온 아주 작은 소수민족 도구로부터 그것을 벗어나기 위해, 아무리 기본적인 정책도 부족한 상태에서 우리가 공급원으로서 사용해서는 안 되는 웹 사이트의 데이터를 더 쉽게 편집하기 위해, 같은 지친 VE를 우리의 목을 졸라매고 있다.둘 다 집어치우면 많은 위키백과 편집자들이 이 노력보다 훨씬 더 행복해질 것이다.프람 (대화) 08:23, 2017년 5월 19일 (UTC)

WMDE는 a) 조직이 아니라 "열여덟 번의 시도에서 같은 지친 VE를 목구멍으로 밀어넣는다";b) 이것은 단순히 엔이 아니라 다른 위키에도 사용된다.WP; 그리고 c) 2010년 위키텍스트 편집자와 VE 사이의 퇴보를 제외하고 기능 패리티가 있어야 한다고 제안할 만한 것은 어디에도 없으며, 나는 당신이 대부분의 편집자들이 사용하고 있다고 믿는 편집자라고 생각한다(이것은 이의를 제기하지 않겠다).d) Parsoid를 기반으로 구축된 2017 Wikitext 편집기도 있으며, 이 기술을 가능하게 하는 것도 의심의 여지가 없다.나머지 실수에 대해서는 언급하지 않겠다. --Izno (대화) 12:02, 2017년 5월 19일 (UTC)

VE를 우리의 목구멍으로 밀어넣는 것은 열여 번째의 시도다. 그리고 이번에는 WMF 대신 WMDE에 의해 행해진다. 와우, 큰일이다.대부분의 다른 위키도 VE가 아닌 위키텍스트 편집기를 주로 사용하지만, 백분율은 아마도 여기와 다를 것이다.당신의 요점 c 역시 요점을 놓친다: 자연 패리티가 필수는 아니지만, 대부분의 편집자를 끌어들이지 못한 프로젝트에 피쳐를 추가하는 것은 어리석다(확실히 그것이 일반적인 주제이기 때문이다), 그리고 일반적으로는, 가장 인기 있는 편집자(그리고 또 그 후에)에 피쳐를 추가하는 대신에, 대부분의 편집자를 끌어들이지 못한 프로젝트에 피쳐를 추가하는 것은 (그리고 훨씬 더 많은 시간과 자원을 절약한다.)또는 소수 편집자들에게는 절대 그렇지 않다.여기서(그리고 과거에 너무 자주) 행해진 일은 다시 대부분의 편집자들이 실제로 사용하고 필요로 하는 것을 무시한 채, 대신 애완동물 프로젝트(또는 여기 한 번에 두 개의 애완동물 프로젝트)를 하러 가는 것처럼 보인다.프람 (토크) 12시 20분, 2017년 5월 19일 (UTC

순환 참조 문제에 대해서는, Wikidata 프로젝트 채팅에 대해 토론을 시작했다.대부분 QuickStatements 배치의 결과인 것 같다.Jc86035 (대화) {{re Jc86035}}}}}
을(를) 사용하여 2017년 5월 19일 12:14(UTC) 회신

고마워. 프람 (대화) 12시 20분, 2017년 5월 19일 (UTC)

다소 근본적인 문제(많은 문제 중 하나, 그러나 지금 내가 생각하는 것 중 하나): 현재 enwiki에서 wikidata로 갈 때, 나는 enwiki에 로그인되어 있지만 wikidata에는 로그인되어 있지 않다.만약 쉬운 편집 도구로 이런 일이 일어난다면, 내 wikidata 편집은 내 계정으로 이루어지는 것이 아니라 IP로 나타날 것처럼 보인다.좋지 않아...프람 (토크) 12:42, 2017년 5월 19일 (UTC)

이상하네, 다른 자매 사이트에도 있어?우리는 사람들이 우리의 다양한 자매 사이트에 로그인하도록 하는 두 가지 방법을 가지고 있고 그것은 일반적으로 잘 작동한다.—DJ (대화 • 기여) 13:06, 2017년 5월 19일 (UTC)

다른 언어에서는 일어나지 않지만(임의의 기사 => 스웨덴어 위키백과를 통해 단지 테스트했을 뿐), 예를 들면 그런 것 같다.커먼즈도.그리고 메타에서.프람 (대화) 13:24, 2017년 5월 19일 (UTC)

그래, 그러니까 그냥 교차 도메인.우리는 이것을 하기 위해 두 가지 방법을 가지고 있다.첫번째는 쿠키와 이미지 사용이다.이 방법은 쿠키 교환에 대한 더 엄격한 규칙을 가지고 있는 더 현대적인 브라우저에서 쉽게 깨진다.이를 어기는 또 다른 이유는 개인 정보 보호 확장(또는 추가 차단)일 수 있다.그 이유는 우리는 이것을 위해 1픽셀의 이미지를 사용하며, 때때로 이 이미지들은 픽셀을 추적하는 것으로 간주되기 때문이다.개인 검색 모드도 영향을 미칠 수 있다.

우리가 사용하는 두 번째 방법은 Javascript이다.Javascript 방법은 일반적으로 매우 신뢰성이 높으며, 우리가 아는 한 브라우저에서 Javascript를 비활성화한 경우에만 고장날 수 있다.만약 당신이 JS를 무력화시키지 않았고, 무언가가 그것을 방해할 수 있었다면, 우리는 그것이 무엇인지 알아낼 필요가 있다. 왜냐하면 그것은 우리가 알고 있는 것보다 훨씬 더 많은 사람들에게 영향을 줄 수 있기 때문이다.—DJ (대화 • 기여) 14:29, 2017년 5월 19일 (UTC)

리비전슬라이더

비르기트 뮐러(WMDE) 14:39, 2017년 5월 16일 (UTC)

@Birgit Müller (WMDE): 막대들 중 하나를 가리키면, 그 개정안에 대한 정보를 보여주는 팝업 풍선이 있다.모노북에서는 읽을 수 없을 정도로 작다.common.css -에 규칙을 추가하여 수정하고 싶지만, 문제의 HTML 요소에 대해 전혀 알 수 없기 때문에 그렇게 할 수 없다.왜냐하면 파이어폭스의 "Inspect 요소" 기능을 사용하면 팝업이 사라지고, 팝업이 끝난 요소를 검사하고 있기 때문이다.내가 직접 고칠 수 있든 없든(현재 '없든' 상태에서는 글꼴 크기를 늘릴 것을 제안한다.--Redrose64 🌹 (토크) 20:43, 2017년 5월 17일 (UTC)

@Redrose64:피드백 고마워!나는 일반적으로 접근성 문제를 위해 가짜 표를 만들었다.common.css 규칙의 경우, 당신은 아마도 "oo-ui-popupWidget-up" 클래스와 함께 div가 필요할 것이다(Extras > Web-Developers > Inspector로 가면 Firefox에서 이것을 얻을 수 있고, 그리고 그 위에 나타나는 콘솔에서 왼쪽 위에 있는 버튼은 당신이 요소 위에 있을 때 즉시 당신에게 모든 정보를 보여주는 버튼이다).이게 도움이 되었으면 좋겠어!Lea Voget (WMDE)(대화) 11:41, 2017년 5월 18일 (UTC)

이것은 정말 유용할 가능성이 있는 것 같다.몇 가지 멍청한 질문: 왜 그것이 가장 편리할 수 있는 수정기호 역사 페이지에 나타나지 않는가? 그리고 무엇이 수정기호의 수를 결정하는가?– "툴은 현재 화면에 표시되는 리비전의 데이터만 가져오며(최대 500 리비전의 경우), 추가 리비전에 대한 데이터는 사용자가 화살표를 사용하여 타임라인에서 앞뒤로 이동할 때만 로드된다"는 것은 분명 여기서 말하는 바는 아니다. 왜냐하면 화면에 표시되는 리비전의 수는 항상 다음과 같기 때문이다.한 페이지 또는 두 페이지 중 하나50을 주는 순간, 그것을 500으로 바꾸는 방법을 알고 싶다.사실, 수정 내역 페이지에 표시할 500개 이상의 수정본을 수동으로 추가하는 방법 말고도 알고 싶다.&limit=5000아니면 URL에 무엇이 들어있든 간에, 그것을 할 수 있는 방법, 선호도, 무엇이든지 간에?Justlettersandnumber (대화) 13:15, 2017년 5월 18일 (UTC)

나는 그것을 "역사 보기" 디스플레이로 옮기려는 생각을 지지한다. 그것은 디프프화의 최상위에 있는 것과는 대조적이다.디프를 보면 그 싱글 편집이 정말 흥미로워.반대로 슬라이더는 페이지 개정 이력을 검토할 때 매우 유용한 도구처럼 보인다. --Tryptofish (토크) 19:28, 2017년 5월 18일 (UTC)

역사를 찾아보는 것이 아마도 더 나은 메커니즘이 되겠지만, 나는 그것을 디프 스크린에서 멀리 옮기는 것을 지지하지 않을 것이다.RevisionSlider를 watchlist와 함께 불쾌한 이슈를 해결책으로 사용한다(여러 탭이 해당 페이지를 마지막으로 본 이후 한 페이지의 변경사항을 검토하도록 요구하는 경우가 있다). --Izno (대화) 20:33, 2017년 5월 18일 (UTC)

"단일 페이지의 변경사항을 검토하기 위해 여러 탭이 필요할 때도 있는 일"이란?난 절대 그럴 필요가 없어.나는 내 워치리스트를 열고, 바닥으로 가서 내가 굵은 글씨체에 도달할 때까지 페이지를 올려다본다. 그리고 나서 계속 위로 올라간다. 이번에는 내가 갈 때 "diff" 링크를 클릭한다.모두 한 탭에 있다.두 번 이상의 편집이 있는 경우 "cur" 링크 중 하나를 선택할 수 있는 "history" 링크를 사용할 수 있다.그러나 한 탭 이상은 필요 없다. --Redrose64 🌹 (대화) 22:04, 2017년 5월 18일 (UTC)

@Redrose64:캡:T10681은 현재 내가 작업하고 있는 문제를 기술하고 있다. "N 변화"는 M일과 M+1로 나뉜다. (적어도 Overnight)내가 M일의 총 디프피를 클릭하면, M+1 또는 b) 수정기호 또는 그 전임자의 총 디프프가 있는 a) 두 번째 탭이 필요하며, 이 탭은 M+1을 M과 같은 탭에 포함시킬 수 있다. '이전' to All-New 수정기호에서 "cur"는 때때로 내가 가장 최근의 어떤 것도 읽지 않은 것으로 표시하지 않았기 때문에 항상 작동하지 않는다.watchlist에 저장된 편집(1k 변경사항) --Izno(토크) 00:48, 2017년 5월 19일(UTC)

아, 그렇구나.Preferences → Watchlist로 이동하여 "최근뿐만 아니라 모든 변경사항을 표시하도록 감시 목록 확장"을 활성화하십시오. 이를 비활성화하면 문제가 너무 많이 발생함(예를 들어, "감시 목록에서 부분 편집 숨기기"를 활성화하고 지정된 페이지에 대한 최근 편집이 마이너로 표시된 경우 해당 페이지에 대한 정보를 얻을 수 없음).너무 놓치기 쉬워. --Redrose64 🌹 (토크) 07:48, 2017년 5월 19일 (UTC)

별도로 디프프 및/또는 리비전 기록에서 허용하는 사용자 환경설정 설정이 있을 수 있다.나 자신, 디프스에서 보는 것은 별로 좋아하지 않지만, 개정 이력 페이지에 있으면 좋을 것 같아. --Tryptofish (토크) 00:05, 2017년 5월 19일 (UTC)

예, 사용자 환경설정이 괜찮을 겁니다.Lea Voget(WMDE), Birgit Müler(WMDE), 이에 대한 언급 또는 표시된 수정본 수 변경에 대한 위의 질문에 대한 언급이 있으십니까?Justlettersandnumber (대화) 08:16, 2017년 5월 19일 (UTC)

@Tryptofish:, @Justlettersandnumber:피드백 고마워!나는 관련 페이브릭터 티켓에 대한 사용자 선호도를 갖자는 너의 제안을 추가했다.@Justlettersandnumber:RevisionSlider를 사용하여 50개 이상의 수정본에 도달할 수 있다는 것을 정확히 이해했는가?아니면 500개의 바를 동시에 보고 싶으세요?첫 번째는 이미 일어나고 있다.RevisionSlider는 500개의 리비전의 정보를 로드하는데, 이는 화면에 표시되는 막대보다 훨씬 많다.한 번 측면의 화살표를 클릭하여 이전 버전 또는 최신 버전으로 이동하면 더 많은 리비전을 다시 로드하여 역사에서 더 멀리 되돌아가려면 리비전을 다시 표시하십시오.만약 이것이 당신의 뜻이 아니라면, 나를 바로잡아 달라 :) Lea Voget (WMDE) (대화) 14:48, 2017년 5월 19일 (UTC)

감시 목록 알림

감시 목록 알림을 트리거하지 못하도록 봇 편집을 비활성화하는 방법이 있는가? - Mlpearc(개방 채널) 14:34, 2017년 5월 19일(UTC)

@Mlpearc:응, 있어.감시 목록의 맨 위에는 "감시 목록 옵션"이라는 큰 상자가 있다.그 상자 안에 숨기기:라고 쓰여진 곳이 있고, 그 다음엔 방사청 상자가 여러 개 있다.그 중 하나는 "봇"이라고 말한다.거기에 체크 표시를 하면 봇 편집이 숨겨질 거야.~ ONUnicorn^{(Talk Contribs)} 문제 해결 14:51, 2017년 5월 19일 (UTC)

(충돌 편집) Special:에서 "내 감시 목록의 페이지 또는 파일이 변경될 때 전자 메일 보내기"로 설정된 전자 메일을 참조하십니까?선호도#mw-prefection-personal?거기서 봇 편집은 생략할 수 없을 것 같아."알림"은 보통 위키피디아를 가리킨다.특수에 설정이 있는 알림(이전의 에코):기본 설정#mw-prefection-echo. 그러나 이 기능은 감시 목록을 포함하지 않는다.실제 감시 목록은 Special:의 설정으로 봇 편집 내용을 숨길 수 있다.Preferences#mw-prefection-watchlist 또는 Special:워치리스트, 하지만 이메일에는 영향을 주지 않는 것 같아(테스트 안 해봤어)프라임헌터 (대화) 14:54, 2017년 5월 19일 (UTC)

@ONUnicorn:이미 확인했으니 좀 더 정확하게 해야죠, @Prime.헌터: 응, 나는 봇이 내 목록에 있는 페이지를 변경할 때 이메일을 받는 것을 말하는 거야. - Mlpearc (오픈 채널) 15:03, 2017년 5월 19일 (UTC)