위키백과:마을 펌프(기술)

참고: 아래 스크린샷을 참조하십시오.T344562를 참조하십시오.

Windows 10 Pro PC에서 Firefox를 사용하고 있습니다.둘 다에 대한 최신 표준 버전입니다.Edge 브라우저에서는 이러한 현상이 발생하지 않습니다.로그인 여부.위키백과에서 로그아웃했는데 파이어폭스에 문제가 있습니다.그래서 그것은 나의 JS와 CSS 파일이 아닙니다.또한 모든 Firefox 애드온을 비활성화한 다음 모든 Firefox 창을 닫았습니다.파이어폭스를 시작했는데 아직 파이어폭스에 문제가 있습니다.추가 기능이 없고 로그인되지 않았습니다.

문제 테이블은 모두 테이블 내의 템플릿을 사용합니다.그러나 {{flaglist}}을(를) 사용하는 테이블에는 문제가 없습니다.

1인당 총 보건 지출에 따른 국가 목록을 참조하십시오.두 테이블 모두 {flagg}을(를) 사용합니다.

시각적 편집기를 엽니다.두 표 중 하나의 오른쪽을 클릭합니다.행이 하나의 셀 위로 이동하는 이상한 결과를 기록합니다.다른 행의 오른쪽을 클릭하고 해당 행이 한 셀 위로 이동하는 것을 확인합니다.표 위 또는 아래를 클릭하면 문제가 해결됩니다.

도움말에 대한 시각적 편집기를 열었습니다.테이블을 클릭하여 여러 테이블 중 오른쪽을 클릭해 보았습니다.더 가까이, 더 멀리.저는 지금까지 단 한 개의 테이블에서만 그 문제를 지적했습니다.이 표에서 시각적 편집기를 사용하려면 해당 표로 이동해야 합니다.

• 도움말: 표 #표 셀 템플릿

선택한 테이블 셀 템플릿에 대한 템플릿 출력

템플릿 사용	{{Yes}}	{{No}}	{{Dunno}}	{{N/A}}	{{N/A N/A}}	{{n/a n/a}}
템플릿 사용	네.	아니요.	?	—	없음	n/a
템플릿 없음	네.	아니요.	?	—	없음	n/a

저는 그 문제를 가운데 줄에서만 봅니다.오른쪽을 클릭하고 행이 한 셀 위로 이동할 때까지 닫기를 클릭합니다.그것은 항상 일어나는 일이 아닙니다.

목록 문서에 있는 테이블 중 하나의 몇 줄에서 템플릿을 제거했습니다. 이것으로 문제가 해결되었습니다.그리고 위의 작은 테이블은 템플릿을 사용하여 가운데 줄에만 버그가 있습니다. --Timeshifter (talk) 15:00, 2023년 8월 14일 (UTC) Reply [Reply]

여기서 좋은 답변을 받지 못하면 팹에 버그 보고서를 간결하게 게시하고 Visual Editor로 태그를 지정하고 문제를 시각화하는 데 도움이 되는 스크린샷을 사용해 보십시오.Phab 버그 보고서를 만드는 링크입니다.–Novm Linguae (대화) 00:01, 2023년 8월 15일 (UTC) 회신 [회신]

노벨 링구아.T344562 참조

여기에도 게시됨:

템플릿 토크:플래그g#한 셀 위에서 행을 이동합니다.Flagg 템플릿을 사용한 테이블 버그

--Timeshifter (대화) 2023년 8월 19일 22:34 (UTC) 응답 [응답]

토론 페이지 중에는 자동으로 필수 들여쓰기가 선택되기 때문에 보통 회신 링크를 클릭하여 회신합니다.축소 템플릿 {{collapse top reply with details 1}}을(를) 사용하면 문제가 발생합니다.토론을 간결하고 다른 사용자가 쉽게 탐색할 수 있도록 {{prefix bottom}}개의 의견을 직접 작성했습니다.템플릿을 축소하기 전에도 들여쓰기가 자동으로 적용되며, 이후 {{collapse bottom}} 아래의 후속 텍스트도 다른 편집으로 추가 들여쓰기를 수동으로 제거할 때까지 숨겨지거나 보이지 않습니다.

제 인터넷 속도가 느려지거나 위키백과에서 유지보수를 위해 바쁘다는 오류가 발생하는 경우가 많은데, 이러한 불필요한 들여쓰기를 제거하는 데는 시간이 걸립니다. (그리고 저는 지금도 인터넷 속도 문제를 겪고 있습니다.) 그리고 저는 항상 나중에 사용자들이 저를 오해할까봐 걱정됩니다.

이러한 어려운 상황을 방지하기 위해 들여쓰기가 있더라도 나중에 텍스트가 보이지 않도록 축소 템플릿을 업데이트할 수 있는 방법이 있습니까?

Bookku (대화) 2023년 8월 18일 06:53 (UTC) 회신 [답장]

오늘 설명된 문제를 피할 방법이 없습니다.이즈노 (대화) 19:38, 2023년 8월 18일 (UTC) 회신 [답장]

햄 오케이는 그것과 함께 살 것입니다.메모하고 답장해주셔서 감사합니다. Bookku (대화) 2023년 8월 19일 05:45 (UTC) 회신 [답장]

뭔가 자꾸 기억이 새요.제가 사용하는 스크립트 중 하나일 수도 있지만 잘 모르겠습니다.위키피디아 탭(다른 모든 탭 제외)은 잠시 방치하면 불가피하게 1.5G 이상의 RAM을 사용하기 시작합니다.정확히 무엇이 원인인지 어떻게 알 수 있습니까?비발디 6.1.3035.257입니다. 하지만 몇 달째 계속되고 있습니다.Festucalex • talk 2023년 8월 18일 09:52 (UTC) 회신 [답장]

동작 phab:T205127 문제를 설명하시겠습니까?불행하게도 그것의 원인을 알아내는 데 성공한 것 같지는 않습니다.웁"?2023년 8월 18일 10:28 (UTC) 회신 [답장]

@엉덩이:아 네, 그럴 것 같네요.2018년부터 오픈해서 아쉽다 (!) ~ 페스투칼렉스 • 토크 11:19, 2023년 8월 18일 (UTC) 회신 [답장]

사용자 스크립트나 다른 것에 끝없는 루프가 없는 한 스크립트 자체가 메모리 누수를 야기하지 않아야 한다고 생각합니다.메모리 누수는 일반적으로 브라우저의 코드에 문제가 있는 것으로 알고 있습니다.–Novm Linguae (대화) 2023년 8월 19일 01:03 (UTC) 응답 [응답]

전통적인 메모리 누수와 동일하지는 않지만, 자바스크립트로 스토어 고블러가 발생할 수 있습니다. (하지만, 이 상황이라면 모르겠습니다.)예를 들어 스크립트는 새 이벤트 수신기를 지속적으로 등록하여 메모리를 소모하고 성능을 저하시킬 수 있습니다.아이작(talk) 2023년 8월 19일 01:45, UTC 답장 [답장]

웹 개발은 아니지만 브라우저 제작자와 웹 개발자들이 웹을 완전한 데스크톱 OS의 기본 런타임 환경(예: wasm, 최근에는 WebGPU)만큼 강력하고 궁극적으로 대체하는 "플랫폼"으로 보기 시작한 이후로 이것은 유지할 수 없게 되었습니다.애플이 사파리를 메모리를 너무 많이 사용하는 자동 충돌 탭으로 바꾸자 사람들은 그것이 줌과 같은 미션 크리티컬 사이트와 디즈니+와 같은 일상적인 사이트를 깨트렸다고 불평했고, 그래서 애플은 이에 동의했습니다.DFlhb (대화) 2023년 8월 19일 10:08 (UTC) 회신 [회신]

"이것"이 무엇을 의미하는지 잘 모르십니까?장시간 실행되는 프로그램의 메모리 누수는 항상 해결해야 할 문제로 간주되어 왔습니다(증가 속도가 작업의 우선 순위에 영향을 주지만).웹 사이트에서 제공하는 Javascript 파일의 스토어 고블러는 브라우저 공급업체에서 수정할 수 없으므로 브라우저는 문제 발생 탭에 할당된 리소스를 방해하여 다른 탭이 영향을 받지 않도록 균형을 유지할 수 있습니다.아이작(talk) 13:23, 2023년 8월 19일 (UTC) 답장 [답장]

"이것" = 웹 사이트 메모리 유출이 브라우저에 의해 자동으로 방지됩니다.브라우저는 합법적인 비 버그 목적으로 높은 리소스 사용을 방지하지 않고는 이를 수행할 수 없습니다.DFlhb (대화) 2023년 8월 19일 14:10 (UTC) 회신 [회신]

설명해 주셔서 감사합니다.(Novem Linguae가 이 시나리오를 언급한 것은 아니라고 생각합니다.) Isaacl (대화) 2023년 8월 19일 (UTC) 14:15, Reply[응답]

저는 일부 페이지(리오넬 메시, 하비에르 마스체라노)가 더 이상 사람들의 성을 이탈리아어로 발음하지 않는다는 것을 알아차렸습니다.원래 성 발음을 어디에 써야 하는지에 대한 가이드라인이 있습니까?위키데이터에서?Elias Lönrot에서 나는 그것을 각주에 썼습니다. -- Carnby (대화) 19:33, 2023년 8월 18일 (UTC)응답[응답]

@Carnby: 여기 위키백과에서 무엇이든 합니다.스타일/발음 설명서가 도움이 됩니까?Wikidata에 관한 한, 한 항목에 대해 여러 P898 및 P443 속성을 저장할 수 있습니다.xaosflux^Talk 20:29, 2023년 8월 18일 (UTC) 회신 [답장]

@샤오스플럭스 솔직히 메시, 마스체라노, 디 마리아, 베르골리오, 마일리(이탈리아계 아르헨티나인), 아데토쿤보(요루바계 그리스인), 뢴로트(스웨덴계 핀란드인) 등 다른 나라에서 유래한 영어가 아닌 이름에 대해서는 찾을 수 없습니다.

그건 기술적인 질문이 아닙니다.저는 그 주제가 "원어"와 강한 유대감을 갖지 않는 한 (그들은 유창하고, 그들은 1세대 이민자 등) 그것이 불필요하다고 생각하는 경향이 있습니다.Nardog (대화) 2023년 8월 19일 01:43 (UTC) 응답 [응답]

위키데이터에 원래 발음을 저장하기로 했습니다. -- Carnby (talk) 08:59, 2023년 8월 19일 (UTC)Reply [reply]

• #:~:text= on en.wikipedia.org
• 다음 텍스트는 URL의 일부가 아니며 사용자를 식별합니다.
• 구글 북 인용에서도 발생하지만 NAME=VALUE 쌍이 다릅니다.
• 0mtwb9gd5wx (talk) 00:13, 2023년 8월 19일 (UTC) 회신 [회신]

  자동 정리 ? .. 0mtwb9gd5wx (talk) 00:15, 2023년 8월 19일 (UTC) 회신 [회신]

  해당 검색 쿼리에 잘못된 긍정이 있습니다.내가 #:~:로 찾은 첫 번째 항목은 여기에 있지만, 그것은 괜찮을 것 같습니다.사용자를 식별하지 못하는 것 같습니다.다른 예는 없나요?이것들을 치우기 위해 도움을 요청하고 있습니까? – Novm Linguae (대화) 01:15, 2023년 8월 19일 (UTC) 회신 [응답]

  이것의 목적은 사용자를 식별하기 위한 것이 아니라(가능하다고 생각하지만) 페이지의 특정 텍스트에 연결하기 위한 것입니다.(즉, 구글이 크롬에 일방적으로 추가하기로 결정한 것 중 하나이며, 다른 브라우저들 사이에서는 지원이 다양하지 않습니다.)리틀 퍼퍼스 (대화) 2023년 8월 19일 01:30 (UTC) 응답 [응답]

  템플릿:인용 스타일 문서 #url에는 추적 매개 변수를 생략하도록 되어 있지만 이를 추적 매개 변수라고 부르지는 않을 것이며 "링크가 참조된 특정 페이지를 가리킬 수 있습니다."라고도 표시됩니다.주로 링크에서 페이지 번호를 줄 수 있는 PDF 파일을 말하는 것 같습니다.구글의 정보를 빼라는 지침이 있습니까?text=지원되는 브라우저가 참조에서 사용 중인 페이지 부분으로 바로 이동하는 경우?아마 거의 모든 경우에text=was left는 구글 링크를 클릭하고 의미를 모른 채 전체 URL을 복사한 사용자일 뿐이지만, 가이드라인은 제거된 곳에서 더 많은 정리로 이어질 수 있습니다.프라임헌터 (대화) 2023년 8월 19일 08:59 (UTC) 답장 [답장]

  Firefox에서는 지원되지 않지만 Safari에서는 지원됩니다.Aaron Liu (대화) 16:05, 2023년 8월 19일 (UTC) 회신 [응답]

  @Novm Linguae님, 이와 같은 검색을 의도하신 것 같습니다. 일반 검색은 특수 문자와 일치하지 않습니다. Qwerfjktalk 2023년 8월 20일 14:18 (UTC) 응답 [응답]

  새로운 질문에 시간이 초과되었지만 올바른 방법을 알려주셔서 감사합니다.–Novm Linguae(대화) 2023년 8월 20일(UTC) 15:05 응답 [응답]

  (충돌 편집)

  그 검색은 나에게 효과가 없지만, 만약 내가 문어를 탈출한다면 그것은 효과가 있습니다.이 검색(insource:/\#:~:text=/)약 23k 결과를 반환합니다.

  —Trapist the monk (talk) 2023년 8월 20일 15:06 (UTC) 응답 [응답]

  문어소프는 특별한 정규 표현식 문자가 아니기 때문에 어떻게 작동하는지 잘 모르겠지만 검색 정규 표현식이 이상하게 작동합니다. Qwerfjktalk 2023년 8월 20일 21:00 (UTC) 회신 [답장]

  검색은 대부분의 사람들이 익숙한 posix/pcre와 같은 형식의 정규식을 사용하지 않으며 #는 실제로 메타 문자입니다.문서, 문법.—Cryptic 2023년 8월 20일 21:05(UTC)응답하라[응답하라]

  ~도 그렇지만, 우리가 빠져나간 것 같아요.Certes (대화) 2023년 8월 20일 22:22 (UTC) 응답 [응답]

개인 키보드 단축키를 변경할 수 있는 방법이 있습니까? -Proxima Centari (talk) 00:19, 2023년 8월 20일 (UTC)Reply[reply]

@프록시마 센타리:이 페이지는 제가 찾을 수 있는 한 가깝습니다.리틀 퍼퍼스 (대화) 2023년 8월 20일 00:41 (UTC) 응답 [응답]

감사합니다! - 프록시마 센타리 (토크) 2023년 8월 20일 (UTC) 00:43 답변 [답장]

날짜가 지정된 유지 관리 범주에서 발견한 문제에 대해 묻고 싶습니다.이러한 일이 일어난 것은 이번이 유일한 일이 아니며, 대신 최근에 이러한 사례가 많이 있었습니다. 하지만 범주를 올리겠습니다.CS1 유지보수: 2022년 12월 현재 DOI 비활성화 상태입니다. 이는 제가 찾은 가장 최근의 사례이기 때문입니다.

어떻게 된 일인지는 8월 1일에 빈 것으로 삭제되었지만, 그 다음 주 중 어느 때인가 다시 채워졌고, 그 결과 8월 7일에 삭제를 해제해야 했습니다. Special:Categories를 원했지만, 그 다음 주 언제 다시 비워져 두 번째로 삭제해야 했습니다.

물론 날짜가 지정된 유지 관리 범주에 태그를 지정하는 것은 일반적인 날짜가 지정되지 않은 유지 관리 범주가 가끔 사용하는 "비워도 유지 관리" 옵션에 대한 가치는 없습니다. 하지만 위키백과 사람들이 이러한 유지 관리 범주에 대해 반복적인 delete-undelete-redelete 사이클을 거치는 것도 큰 가치는 없습니다.따라서 유지 관리 템플릿이 실제로 존재하는 경우 날짜가 지정된 범주만 생성하고, 실제로 존재하지 않는 경우 날짜가 지정되지 않은 일반적인 "crapcatcher" 범주를 대체하여 이러한 상황이 "원하는" 빨간색 링크로 표시되지 않도록 하는 등 이 문제를 피할 수 있는 다른 방법이 있습니까?Bearcat (대화) 2023년 8월 20일 13:03 (UTC) 응답 [응답]

해당 날짜 태그가 있는 수정판으로 되돌려서 카테고리에 페이지가 다시 나타난 페이지가 다시 나타난 것 같습니다.템플릿은 다음을 사용해야 합니다.#ifexist범주를 생략하지만 페이지당 총 500개가 허용되는 고가의 파서 기능입니다.그러면 이러한 템플릿이 많은 페이지에서 문제가 발생할 수 있습니다.또한 새 유지관리 범주의 생성이 지연될 수 있습니다.MediaWiki 메시지의 정규식과 같은 MediaWiki 기능을 사용하여 특정 범주 이름이 존재하지 않는 경우 숨겨진 범주로 취급해야 한다고 말하고 싶습니다.그러면 기본 설정이 있는 일반 독서자와 등록된 사용자는 범주 목록에서 보기 흉한 빨간색 링크를 볼 수 없습니다.당신의 문제를 해결할 수는 없겠지만, 저는 이것이 빨간색 유지보수 카테고리에서 더 중요한 문제라고 생각합니다.프라임헌터 (대화) 2023년 8월 20일 14:41 (UTC) 답장 [답장]

많은 실제 유지 관리 템플릿이 사용됨#ifexist(대부분 템플릿을 통해):날짜가 지정된 유지 관리 범주 또는 템플릿:수정/카테고리 또는 모듈:메시지 상자)를 눌러 카테고리를 채웁니다.템플릿에 잘못된 날짜 매개 변수가 있는 아티클입니다.그때 아노미 BOT의 DateCategoryCreator 작업은 2시간마다 해당 카테고리를 조사하여 카테고리의 날짜 하위캣을 다시 연결한 기사를 찾습니다.월 및 범주별로 정렬된 위키백과 유지 관리 범주:위키백과 카테고리를 월별로 정렬하여 자동으로 만듭니다.CS1 템플릿이 제가 모르는 유사한 작업을 수행하는 것이 적절한지 여부입니다.Anomie⚔ 2023년 8월 20일 18:11 (UTC) 회신 [회신]

우리의 가장 큰 페이지의 사용 횟수를 고려할 때, 가능성은 없습니다.이즈노 (대화) 2023년 8월 20일 18:20 (UTC) 회신 [답장]

음, 확실합니까?cs12에 서식하는 유일한 날짜가 지정된 메인 고양이는 다음 범주의 하위 고양이입니다.CS1 유지 관리: DOI가 비활성 상태입니다.현재 ~2,000개의 기사가 있습니다. doi-broken-date=(카테고리에 있는 모든 것:CS1 유지: 2023년 8월 현재 DOI 비활성화).날짜가 지정된 유지 관리 고양이는 다음에 종속되어 있기 때문입니다. doi-broken-date=cs12 모듈은 비싼 기능만 호출하면 됩니다.mw.title.new ('Category:CS1 maint: DOI inactive as of <month> <year>').exists언제 doi-broken-date=발견되었습니다.한 페이지에 500개 이상의 파라미터가 있을 것 같지 않습니다.언제 doi-broken-date=일치하는 기존 범주가 없는 경우 모듈은 빨간색 연결 고양이와 파란색 연결 고양이를 AnomieB용으로 방출할 수 있습니다.그러면 어떻게든 빨간색 연결된 고양이로부터 파란색 연결된 고양이를 만들 수 있는 OT.Does Anomie BOT 카테고리 페이지 자체에 현재 모든 위키 텍스트를 추가합니다. 아니면 편집자에게 남겨진 연습입니까?

—Trapist the monk (talk) 2023년 8월 20일 18:48 (UTC) 응답 [응답]

AnomieBOT는 날짜가 지정된 범주를 {{Monthly Cleanup Category} 또는 {{Monthly Maintenance Category}}(으)로 만듭니다.범주 참조:2023년 8월 또는 카테고리의 출처가 불분명한 글:일부 예를 들어 2023년 8월부터 분류되지 않았습니다.만약 우리가 원한다면, 물론 CS1 유지 고양이를 위해 다른 템플릿을 할 수 있지만, 저는 여전히 카테고리 페이지에서 단일 템플릿을 제외할 것을 권장합니다(그것이 그러하든 말든).{{CS1 maintenance category}}또는{{CS1 maintenance category/DOI inactive}}아니면 심지어{{CS1 maintenance category DOI inactive}}) 그래서 사람들은 봇을 변경할 필요 없이 내용을 쉽게 조정할 수 있습니다.Anomie⚔ 2023년 8월 20일 19:44 (UTC) 회신 [회신]

봇이 다시 채워지면 삭제된 범주를 다시 생성할 것이라고 생각했습니다.저는 이것이 많은 작업이 필요하지 않을 것이라고 생각합니다. 단지 "월 연도 기준 주제"를 주기적으로 확인하는 것입니다. 물론 많은 가능성이 있습니다. (위키백과가 설치된 지 272개월이 지났고, 각 주제 범주에 대한 것입니다.: "출처되지 않은 기사" 272건, "NPOV 문제" 272건 등입니다.) 하지만 봇에게는 어렵지 않습니다.Nyttend (대화) 11:42, 2023년 8월 21일 (UTC) 회신 [응답]

프로그래밍이 어렵지는 않지만 시간과 리소스가 소모됩니다.이것이 봇이 현재 카테고리에 의존하는 이유입니다.몇 시간마다 54,000개의 카테고리 이름을 쿼리하는 대신 문제가 있는 카테고리를 가진 기사에 플래그를 표시하는 템플릿의 잘못된 날짜 매개 변수가 있는 기사.Anomie⚔ 2023년 8월 21일 12:14 (UTC) 회신 [회신]

저는 AnomieB를 활용한 자동화 솔루션이OT는 여기에 맞지 않습니다.예제 카테고리, 카테고리:CS1 유지보수: 2022년 12월 현재 DOI 비활성, AnomieB에 대해 제대로 이름이 지정되지 않았습니다.OT(그것은 ...을 원합니다.<에서month> <YYYY>). 둘 중 하나를 적용하는 방법이 명확하지 않습니다.{{Monthly clean-up category}}또는{{Monthly maintenance category}}여기서 원하는 범주 제목이 현재 월 및 현재 연도가 아닌 날짜를 사용합니다.

이에 대해 좀 더 생각해 보고 헬프 토크에서 논의를 계속하겠습니다.인용 스타일 1.

—Trapist the monk (talk) 17:49, 2023년 8월 21일 (UTC) 응답 [응답]

도움말에 있는 사람들이 다음과 같이 이야기한다면 이 두 가지 모두 극복할 수 없습니다.인용 스타일 1 그들이 Anomie B를 원할 것이라고 결정합니다.OT의 도움.만약 그들이 그것을 원하기로 결정한다면, 나에게 User talk:아노미 BOT. Anomie⚔ 2023년 8월 21일 19:41 (UTC) 회신 [회신]

스크립트 전용 네임스페이스가 없는 기술적 이유가 있습니까?코딩 모듈과 템플릿을 위한 편집자 간의 협업을 장려하는 공간이 있고, 앞으로 기사를 협업할 초안 공간도 있습니다. 스크립트 전용 공간이 없기 때문에 일반적으로 하위 페이지로 사용자 공간에서 개발됩니다.부정적인 결과는 좋든 나쁘든, 편집자가 다른 사용자의 사용자 페이지를 "존경"(적절한 단어는 아님)하며, 초안, 모듈 또는 템플리트보다 다른 사용자의 페이지를 더 많이 편집하는 것을 꺼릴 수 있다는 것입니다.저는 어떤 페이지도 누구의 것이 아니라는 것을 충분히 오랫동안 알고 있었지만, 그것은 일종의 감정적인 것입니다. 저는 당신의 사용자 하위 페이지로 뛰어들어 "당신의" 초안, "당신의" 템플릿 또는 "당신의" 모듈을 개선하기 시작할 가능성이 훨씬 적습니다.그러나 이러한 모든 경우 사용자는 이를 초안: 또는 템플릿: 또는 모듈: 공간으로 이동할 수 있습니다.스크립트의 경우는 그렇지 않습니다. 스크립트의 협업에 부정적인 영향을 미칠 수 있습니다.아마 저는 완전히 젖었을 것입니다. 만약 스크립트 작성자들이 어떤 사용자 서브페이지에 있든 상관없이 기꺼이 스크립트에 참여한다고 말한다면, 저는 그것을 듣게 되어 기쁠 것입니다. 그리고 우리는 이것을 끝낼 수 있습니다.하지만 사람들이 사용자 스크립트를 조작하기 전에 허가나 다른 것을 요청해야 하는 것처럼 느껴집니다.

이것이 문제인지 아닌지를 평가하기 위해 우리가 볼 수 있는 통계가 있을 수 있습니다. 그리고 저는 WP의 좋은 사람들에게 물었습니다.쿼리를 통해 이 토론과 보고서를 연결할 수 있는지 확인합니다.감사합니다, Mathglot (talk) 2023년 8월 21일 02:04 (UTC) 회신 [답장]

저에게, 그것은 선택에 의해 존중받는 것에 관한 것이는 아닙니다.사용자로 이동할 때:연산 글롯/수정기호 표시ID.js, "편집" 대신 "소스 보기"가 표시됩니다.저는 제가 제안한 변경 사항에 대해 100% 자신이 있더라도 그 페이지를 편집할 수 없습니다.템플릿 편집기 권한이 있지만 관리자가 아닙니다.관리자만 다른 편집자의 .js 페이지를 편집할 수 있는 경우, 사용자 공간에서 스크립트 편집의 공동 작업 문화가 발전할 가능성은 거의 없습니다.그게 말이 된다면요.Jonesey95 (대화) 02:15, 2023년 8월 21일 (UTC) 회신 [회신]

관리자는 .js 페이지를 편집할 수 없으며 소유자 또는 인터페이스 관리자만 편집할 수 있습니다.js는 사용자의 브라우저에서 실행되며 많은 피해를 줄 수 있는 통제 불가능한 언어이기 때문에 보안 문제입니다.이에 비해 템플릿과 모듈은 모니터링되는 서버에서 실행되는 잘 정의되고 제한된 언어를 사용합니다.Johnuniq (대화) 2:22, 2023년 8월 21일 (UTC) 회신 [회답]

이 페이지에는 현재 인터페이스 관리자가 12명밖에 없다고 나와 있습니다.저는 그것이 위의 제 주장을 강화한다고 생각합니다.Jonesey95 (대화) 02:29, 2023년 8월 21일 (UTC) 회신 [회신]

네, 그것은 당신의 주장을 강화하지만 제 주장도 강화합니다. 즉, js 페이지는 보안 문제이며 12개 이상의 사람들이 열지 않을 것이고 일어나지 말아야 한다는 것입니다.Johnuniq (대화) 02:37, 2023년 8월 21일 (UTC) 회신 [응답]

와, 깜짝 놀랐어요!이는 새로운 네임스페이스와 새로운 권한을 강력히 지지하는 것으로 보입니다.신뢰할 수 있는 편집자가 모듈 및 템플릿에서와 같이 스크립트에서 협업할 수 없어야 하는 이유는 무엇입니까?보안 문제가 문제라고는 생각하지 않습니다. 왜냐하면 우리는 모두 공통된 .js에 다른 사람의 스크립트를 가져오거나 설치할 수 있기 때문입니다. 사용자 공간 대신 스크립트 공간에서 가져온 스크립트도 동일하게 적용됩니다.유일한 차이점은 우리가 대본 공간에서 더 신뢰할 수 있는 눈과 손을 가지고 있다는 것입니다. 그것은 윈-윈처럼 보입니다.(충돌 편집)

즉, 한 명의 편집자 소유자(및 12개의 IA)에게 잠재적인 피해를 제한하거나 신뢰할 수 있는 js 편집자들이 거주지에 상관없이 모든 js 파일을 모니터링하고 살펴볼 수 있도록 허용하는 것이 더 나은가요?또한 현재와 마찬가지로 추가적인 보호 기능은 항상 지정된 페이지에 적용될 수 있습니다.Mathglot (대화) 02:48, 2023년 8월 21일 (UTC) 응답 [응답]

예를 들어 사용자 정의 그룹을 허용하는 권한 모델에는 새 네임스페이스가 필요하지 않습니다.편집 제한을 설정할 수 있는 일부 기능이 없으면 보안 문제는 실제로 다음과 같은 중요한 문제가 됩니다.다른 사람이 내 개인 사용자 스크립트를 내 권한 없이 변경하는 것을 원하지 않습니다. 그러면 내 자격 증명으로 브라우저에서 임의의 Javascript 코드를 실행할 수 있기 때문입니다.iacl (talk) 03:01, 2023년 8월 21일 (UTC) 응답 [응답]

이 협업 공간은 MediaWiki 네임스페이스에 있을 수 있습니다.그곳에 살고 있는 스크립트는 그것을 가젯으로 만들지 않습니다. 그것은 그곳의 위치와 미디어위키에 지정되어 있습니다.가젯 - 정의가 가능합니다.협업 스크립트와 가젯은 접두사를 사용하여 구분할 수 있으며 가젯은 이미 하나 또는 적어도 연속된 첫 번째 스크립트를 가지고 있습니다(미디어위키:Gadget-refToolbar.js 및 MediaWiki:RefToolbar.js).

새로운 사용자 권한이 발생할 가능성은 거의 없습니다.WMF에 의해 추가되고 WMF에 대한 요구 사항을 완화하는 데 관심이 없는 인터페이스 관리자. 2FA는 사람들이 IA 권한을 얻는 것으로 알려져 있으며 앞으로도 그럴 것입니다.

비활성 사용자에 의한 스크립트에 대한 데이터베이스 쿼리(이 메트릭은 현재 잘 정의되어 있음)를 사용하여 해당 스크립트를 Inactive_user/script.js에서 새 유지 관리자가 관심을 갖는 new_maintainer/script.js로 이동할 수 있으면 좋습니다.Snävar (대화) 11:15, 2023년 8월 21일 (UTC) 응답 [응답]

사용자 정의 액세스 그룹이 특정 페이지를 업데이트할 수 있는 사용자를 보다 유연하게 관리하는 데 도움이 되는 사용 사례가 있지만, 미디어위키의 WMF가 아닌 배포에서는 더 그럴 수 있습니다. (다른 Wiki 플랫폼에서 작동하는 방법에 대한 예는 포스위키의 액세스 제어 문서를 참조하십시오.) Isaacl (talk) 16:43,2023년 8월 21일 (UTC) 회신[회신]

Isaacl, Re: "...내 브라우저에서 임의의 Javascript 코드 실행을 트리거할 수 있기 때문":스크립트를 가져온 경우에는 이미 그런 상황이 발생하지 않습니까?common.js물론, "내" js이지만, 저는 유용한 스크립트를 많이 가져오고 있습니다. 그리고 저는 그들이 제 뒤에 있는 스크립트를 변경하는 것이 유익하다고 믿습니다.변경사항이 보이지 않더라도 신뢰하기 때문에 가져오지만, 선의의 스크립트 변경도 손상될 수 있습니다.신뢰할 수 있는 스크립트 편집자들의 커뮤니티가 아닌 한 사람의 통제 하에 있는 것이 어떻게 더 나은가요? 그들은 무언가 잘못된 것을 발견했을 때 아무 시간대에서나 뛰어들 수 있습니다.제가 보기에 12개의 IA만 있는 것과 같은 보안은 실제로 존재하지 않습니다. 신기루입니다. 스크립트를 전혀 가져오지 않는 한 안전합니다.

하지만, 당신의 반대는 여전히 정당한 것이므로, 어떻게 할 수 있는지 봅시다.가져온 스크립트가 수정될 때마다 자동으로 비활성화되어 사용자가 직접 다시 활성화할 수 있거나(스크립트를 본 후 또는 작성자만 신뢰할 수 있음), 또는 스크립트 작성자가 작업한 RFC와 유사한 스크립트 토크 페이지 토론 후 글로벌하게 다시 활성화될 수 있다면 어떨까요?고객의 변화를 설명/설명하고 커뮤니티가 승인, 거절, 니즈 작업에 대응할 수 있습니까?봇의 실행이 허용되기 전에 초기 승인 및 베타 테스트 기간을 거쳐야 한다는 것을 알고 있습니다.그 후에는 어떨까요? 초기 승인 카트는 코드를 "새로운 작업"이라고 부르지 않는 한 코드를 수정할 수 있습니까?승인 없이 허용하기에는 너무 큰 봇 코드 변경의 종류는 누가 결정합니까?브라우저에서 실행되고 한 명의 사용자만 편집할 수 있는 스크립트를 신뢰할 수 있는 사용자 커뮤니티에서 편집할 수 있는 스크립트보다 안전하게 가져오는 방법은 무엇입니까?

권한 있는 스크립트 작성자 커뮤니티와 스크립트가 변경될 때마다 자동으로 비활성화되는 스크립트와 이를 다시 활성화하는 몇 가지 메커니즘이 있다면 브라우저에서 사용자의 자격 증명을 사용하여 다른 사용자가 작성한 스크립트에 대한 사용자의 반대 의견을 충족시킬 수 있습니까?만약 우리가 반쯤 도착했는데 빠진 조각이 있다면, 그것은 무엇입니까?Mathglot (talk) 2023년 8월 22일 01:18, UTC 답장 [답장]

현재 저는 common.js 파일을 수정하는 시기를 제어하고 특정 사용자 한 명을 신뢰하기로 명시적으로 결정합니다.사용자가 다른 사용자의 사용자 스크립트를 수정할 수 있도록 하는 변경사항은 현재 상황과 다릅니다.사용자 정의 액세스 그룹이 있으면 사용자 스크립트를 변경할 수 있는 사용자와 스크립트를 사용하기 전에 신뢰할 수 있는 사용자 정의 서클을 정의할 수 있는 프레임워크가 제공될 것입니다.아이작(talk) 2:01, 2023년 8월 22일 (UTC) 회신 [회신]

각 업데이트를 검토하거나 버그 수정 및 개선 사항을 누락해야 하지만 작성자가 악성 상태가 되거나 손상되지 않도록 하려면 스크립트의 특정 버전을 이미 가져올 수 있습니다.사용자 스크립트에 대한 모든 것은 편리성/혁신과 보안 사이의 균형입니다.사용자가 임의 코드를 실행하도록 허용하고 코드가 공개된다는 사실은 대부분의 엔지니어에게는 생각할 수 없는 일입니다.각 스크립트와 변경 사항을 검토하는 것은 WMF와 지역사회 모두가 상상할 수 없는 엄청난 일이 될 것입니다.하지만 그것들은 여러분의 위키에서의 삶을 훨씬 더 쉽게 만듭니다, 그렇지 않나요?Nardog (대화) 2023년 8월 22일 02:05 (UTC) 응답 [응답]

위키백과의 문제는 아닙니다. 하지만 여기 계신 분들은 답을 아실 겁니다.

메타:특수:CentralAuth/Nytend는 제 계정 등록 날짜를 2008년 3월 30일로 제시하는데, 그 이유는 제가 2살 된 en:wp, commons 및 de:wp 계정을 연결했기 때문인 것 같습니다.서로 다른 프로젝트에서 계정을 따로 등록해야 했던 때를 기억하는 우리 올드타이머들을 위해, 각 계정의 생성 날짜를 제공하는 곳이 있습니까?아니면 제가 궁금하다면 각 위키의 로그 페이지를 봐야 하나요?Nyttend (대화) 11:37, 2023년 8월 21일 (UTC) 회신 [응답]

각 Wiki의 로그 페이지를 확인해야 합니다.이것은 당신에게 영향을 미치지 않지만, 계정 생성은 2005년 9월에 기록되기 시작했습니다.Graham87 2023년 8월 21일 12:01 (UTC) 회신 [회신]

2023년 8월 21일 15:23 (UTC)

미디어위키 토크에 대한 답변:가젯 전환기.js#2023년 7월 27일 인터페이스 보호 편집 요청: 버튼과 텍스트 사이에 공간을 추가합니다. 대신 OOUI를 사용하는 새로운 버전의 가젯 전환기를 만들었습니다.이렇게 하면 여러 스킨에 걸쳐 라디오 버튼이 보다 균일하게 나타납니다.
이것은 기본 가젯이고 변경 사항이 아주 사소한 것이 아니기 때문에 저뿐만 아니라 더 많은 사람들이 테스트해야 합니다.https://commons.wikimedia.beta.wmflabs.org/wiki/Template:Switcher, 출처: https://commons.wikimedia.beta.wmflabs.org/wiki/MediaWiki:Gadget-switcher.js 에서 데모합니다.
핑 @CM글리, 57번, 잭맥반, 프라임.헌터(이전 토론 참가자) - 알렉시스 재즈(말하거나 나에게) 2023년 8월 21일(UTC) 17:49, 응답[응답]

OOUI는 큰 도서관일 뿐만 아니라 하나의 WMF가 멀어지고 있습니다.라디오 버튼이 조금 더 예뻐 보이도록 위키 다운로드에서 가장 많이 방문한 기사의 모든 독자를 만들 가치가 있다고 생각하지 않습니다.Nardog (대화) 01:48, 2023년 8월 22일 (UTC) 회신 [회답]

Nardog, WMF가 OOUI에서 멀어지고 있습니까?저는 몰랐는데, 어디서 더 읽을 수 있나요?대체품은 무엇입니까? 알렉시스 재즈 (말하거나 나에게) 2023년 8월 22일 09:57 (UTC) 답장 [답장]

장기적으로 OOUI는 미디어위키위키로 대체될 것입니다.Vue를 기반으로 하는 Codex.이것은 약 2년 전에 발표되었습니다.하지만 OOUI는 여전히 오랫동안 있을 것입니다.이러한 전환에는 일반적으로 7년 이상이 소요됩니다.—DJ(대화 • 기여) 2023년 8월 22일(UTC) 11:21 응답[응답]

DJ, 저는 제가 OOUI를 파악하는 데 너무 많은 시간을 투자하기 전에 누군가가 저에게 이것을 말해 줬으면 좋았을 것입니다.
그리고 이제 코덱스.그냥 효과가 없는 것 같아요."Uncaught ReferenceError: require is not defined"는 그것이 던질 수 있는 전부이며, 이러한 코드 예제 중 어떤 것도 실제로 그것을 사용하는 방법에 대한 컨텍스트가 없습니다. :-/ 이해가 안 됩니다.여기서 찾을 수 있는 유일한 예는 User:Jdlobson/rl.js 하지만 저는 그 코드가 무엇을 하는지 이해하지 못합니다. 알렉시스 재즈 (말하거나 나에게) 2023년 8월 22일 17:44 (UTC) 회신 [응답]

@Alexis Jazz 저는 OOOI가 제거되지 않을 것이라고 의심하고, 가까운 미래에 (누군가가 Visual Editor와 많은 다른 것들을 다시 쓰기 전까지는) 발생하지 않을 것이라고 확신합니다. 따라서 OOOI를 좋아하게 되었다면 계속 사용할 수 있습니다. (하지만 항상 싫어했다면, 지금은 정당화됩니다!)

당신의 상황이 무엇인지 잘 모르겠습니다.require질문, 하지만 당신은 그 기능을 얻을 수 있습니다.mw.loader.using이와 같이: [11]

mw.로더.사용.( '@multimedia/코덱스' ).그리고나서( 기능. ( 요구하다 ) {     요구하다( '@multimedia/코덱스' ) ... } ); 

(또는 사용할 수 있습니다.mw.loader.require대신 "디버깅 목적으로만 노출되며 프로덕션 코드에서는 사용할 수 없습니다." [12].

Vue.js를 이미 사용한 적이 없는 한 Codex는 OOOUI보다 더 복잡하며, 이 경우 더 직관적입니다.또한 가젯에서 사용하는 것은 매우 귀찮습니다. 이상적으로는 서버 측 처리에 의존하기 때문입니다.저는 아직 그것을 시도해 본 적이 없으며, 누군가가 그것을 어떻게 하는지 (또는 더 쉽게) 문서화하기를 바랍니다.

만약 여러분이 몇 년 동안 안정적인 방식으로 일을 끝내려고 한다면, 저는 JS 코드에 CSS 클래스를 많이 쓰는 것에 개의치 않는다면, 다른 모든 것보다 훨씬 이해하기 쉬운 Codex의 "CSS 전용 버전"(예: [13])을 추천합니다.마트마 렉스톡 20:13, 2023년 8월 22일 (UTC) 회신 [답장]

매트마 렉스, 저는 "안녕하세요" 대화를 만들고 싶었습니다.더 이상 오류가 발생하지 않도록 라인을 추가했지만 대화 상자가 표시되지 않습니다.위키백과:샌드박스(개정판 1171734233) 그것이 효과가 있었다고 해도, "hello world" 팝업을 생성하는 것은 터무니없는 양의 코드입니다.
OOUI에 대해서 말하자면, 저는 그것과 일종의 애증 관계가 있습니다.어떤 면에서는 너무 제한적이고 결국 해로울 수 있는 CSS 해킹을 적용하게 되고, 어떤 것들은 정말 혼란스러울 뿐입니다. (IIRC가 콤보 박스에서 옵션을 읽고 쓰는 것은 혼란스러웠지만 시간이 좀 걸렸습니다.)OOOUI에서 제공하는 아이콘은 전혀 사용하지 않고, 로딩 시간이 상당히 오래 걸리고, 제 스크립트보다 라이센스가 더 제한적이기 때문에, 저는 저만의 아이콘을 디자인했습니다.그러나 이것들은 OOUI 요소에 적용하기가 더 어려운 것으로 판명되었습니다.제가 읽은 바로는 코덱스를 사용하면 실제로 필요한 아이콘만 로드할 수 있어 보기 좋습니다.OOUI(긴 이름의 항목)의 일부는 스크립트의 크기에 상당히 추가됩니다.
하지만 저는 일반적으로 OOUI를 좋아합니다.저는 다양한 스킨과 스타일링에 대해 생각할 필요가 없습니다.그리고 일단 요령을 터득하면 그것으로 작업하는 것은 괜찮습니다. 알렉시스 재즈 (말하거나 나에게) 2023년 8월 22일 23:33 (UTC) 답장 [답장]

@알렉시스 재즈 세 가지 변화로 작업하는 당신의 예를 들었습니다: [14] (교육 목적으로만)

1. HTML을 만들 필요가 없습니다.<template>원소의예제 코드는 이 구문을 사용하는데, 앞서 언급한 서버 측 처리가 이 구문을 탐지하여 다른 곳에 배치하기 때문입니다.가젯과 같이 이러한 문자열이 없으면 일반 문자열을 사용하여 구성 요소에 전달해야 합니다.
2. 당신은 아무것도 할 필요가 없고 할 수 없습니다.module.exports여러 파일로 구성된 ResourceLoader 모듈이 있을 때 사용됩니다. mw:ResourceLoader/Package 파일
3. 재사용 가능한 구성 요소를 정의하고 있었지만 사용하지 않았습니다.이론적으로, 일단 당신이 당신의 것을 가졌을 때.DialogBasic구성요소, 당신은 그것을 사용할 수 있습니다.<dialog-basic>다른 구성 요소 내부, 사용 중인 것과 동일CdxButton/<cdx-button>(다른 상용판이 필요한지는 잘 모르겠습니다.) 예를 들어 MediaWiki의 맥락에서 재사용 가능한 네임스페이스 선택기 드롭다운이 그런 식으로 정의되어 있다고 가정해 보십시오.하지만 당신이 그것을 전시하고 싶다면, 당신은 그것을 직접 해야 합니다.운 좋게도 이것은 단지 한 줄입니다.

마트마 렉스톡 15:27, 2023년 8월 23일 (UTC) 회신 [답장]

매트마 렉스, 작동하는 것을 확인합니다, 감사합니다!phab:T344680에서 가드너가 언급한 것처럼, 그것은 가젯이나 사용자 스크립트에서 사용을 권장하기에 충분히 능률적이지 않습니다.하지만 특별히 실용적인 ATM이 아니더라도 최소한 작동하는 방법을 아는 것은 좋은 일입니다. - 알렉시스 재즈 (talk or ping me) 02:19, 2023년 8월 24일 (UTC)응답하라 [응답하라]

가젯/스크립트의 Codex 스토리는 아직 잘 지원되지 않습니다.당신은 팹을 찾고 있습니다.T313345.이즈노 (대화) 20:54, 2023년 8월 22일 (UTC) 회신 [답장]

@알렉시스 재즈:이것을 조사해 주셔서 정말 감사합니다.저는 미디어위키 소프트웨어에 익숙하지 않아서 올바른 접근법이 무엇인지에 대해 언급할 수 없지만 베타 테스트를 하게 되어 기쁩니다.https://commons.wikimedia.beta.wmflabs.org/wiki/Template:Switcher 은 각 라디오 버튼과 레이블 사이에 적절한 공간을 두고 있지만, 행 간의 수직 분리는 템플릿에 비해 훨씬 큽니다.Switcher/doc#예:Firefox의 Inspector는 wmflabs 버전이 원래 템플릿에 레이블 요소만 있는 별도의 div에 각 레이블이 있음을 보여줍니다.Cheers, cmʟeeʟaκaτ⎆ɢ▁16 2023년 8월 22일 16:05 (UTC) 회신 [회신]

현재 <갤러리> 태그와 이를 구현하는 템플릿:갤러리는 의 픽셀 값을 사용하여 크기를 조정할 수 있습니다. height=또는 heights=매개 변수도움말 페이지에 다음과 같이 표시됩니다.태그로 표시된 이미지는 사용자 보기 기본 설정을 따르지 않습니다.사용자 선호도 및 사용자 환경설정을 지원할 계획이 있습니까? upright=이미지 썸네일이 현재 수행하는 파라미터는 무엇입니까?아니면 이런 일이 일어나지 않을 이유가 있습니까?Rjjii (대화) 2023년 8월 22일 03:17, UTC 답변 [답장]

어떤 이유에서인지 갤러리는 px 값만 사용하여 렌더링되는 것으로 보입니다. mw:Manual:$wgGalleryOptions는 각 이미지의 기본 픽셀 크기를 설정합니다(거의 또는 그보다 작은 것으로 보입니다).mw도 참조:도움말:images#이미지 갤러리 렌더링.Jonesey95 (대화) 2023년 8월 22일 04:37 (UTC) 회신 [회신]

몇 년 동안 아무도 그것의 코드를 만지지 않았습니다.마지막으로 추가된 것은 슬라이드 쇼 모드였지만, 그 핵심적인 기초는 오래된 것입니다.따라서 코드의 다른 부분을 따라가지 못했습니다.—DJ(대화 • 기여) 2023년 8월 22일 11:25, UTC 답변[회신]

아뿔싸.저는 갤러리가 템플릿에 비해 이미지를 병렬하는 더 깨끗한 방법이 될 수 있다고 생각했습니다.비교를 위해 여러 개의 이미지 또는 단일 이미지가 생성되었습니다.그래도 설명해 주셔서 감사합니다.Rjjii (대화) 02:43, 2023년 8월 23일 (UTC) 회신 [응답]

phab:T315893(특수를 활성화한 사용자의 경우)기본 설정 -> 편집 -> 토론 활동 표시, 편집팀은 모든 토크 페이지 제목에 콜론 뒤에 공백을 추가하기로 했습니다.그들은 이것을 대화가 없는 페이지와 아마도 "특별"이 아닌 페이지에 배포할 계획인 것처럼 들립니다.환경설정 -> 편집 -> 토론 활동 표시" 사용자.여기를 클릭하면 이 공간의 예를 볼 수 있습니다.편집팀은 만약 우리가 그것을 좋아하지 않는다면, 미디어위키를 사용하는 것이 좋다면, 위키 단위로 이것을 재정의해야 한다고 말했습니다.Common.css.

이 변화에 대한 생각?우리는 그것을 무시하는 것을 고려해야 합니까?저는 개인적으로 그것을 무시하고 싶습니다.프로그래머로서 소프트웨어가 "올바른" 제목이 아닌 제목을 제안하는 것이 거슬립니다.이것은 우리가 요구한 변화가 아닙니다.헷갈리는 것 같아요.그래도 다른 생각을 들으니 행복합니다.이번 토론에서 변경하기로 의견이 모아진다면 {{}를 넣겠습니다.미디어위키와의 대화:며칠 후에 common.css.감사해요.–Novm Linguae (대화) 12:44, 2023년 8월 22일 (UTC) 응답 [응답]

공백 문자가 아닙니다.CSS가 만들어낸 갭입니다.복사하여 붙여넣기만 하면 됩니다.팹 티켓에 몇 명의 편집자들이 손찌검을 해댔지만, 저는 여기서 아무도 그것에 대해 겁을 먹은 것을 보지 못했습니다.그것은 한동안 배치되었습니다.이상한 점은 콜론 분리기의 기능이 두 곳 모두 동일함에도 불구하고 토크 페이지에는 있지만 VPT에는 없다는 것입니다.그것은 어디에나 있거나 어디에도 없어야 합니다.Jonesey95 (대화) 2023년 8월 22일(UTC) 14:01 응답 [응답]

모순이 바로 우리가 그것을 숨겨야 하는 이유입니다.NS 접두사가 붙은 페이지 이름이 맞춤법과 일치하도록 만드는 것에 대해 진심이라면, 몇 개의 네임스페이스에서만 수행하거나 제목만 수정하지는 않을 것입니다.당신은 언어 위원회와 같은 전문가들과 상담하고, 변화의 숨결과 위험을 평가하고, 자원을 할당하고, 그것을 지역사회에 홍보할 것입니다.그들이 그렇게 하지 않고 있다는 사실은 이것이 잘못된 생각이라는 것을 말해줍니다.Nardog (대화) 15:50, 2023년 8월 22일 (UTC) 회신 [응답]

아니면 CSS 띄어쓰기를 모든 네임스페이스에 추가해서 무슨 일이 일어나는지 볼 수도 있습니다.베타 배포에 아무런 해를 끼치지 않은 것으로 보입니다.WMF가 배포한 후 80%를 완료한 상태로 두는 많은 베타 자료에 좌절감을 느끼지만(cf Visual Editor, Vector 2022), 이것은 작은 것 같습니다.문제가 발생하면 로컬에서 간격을 제거할 수 있습니다.Jonesey95 (대화) 2023년 8월 22일 16:01 (UTC) 회신 [회신]

더하다.mw-page-title-separator { margin-right: 0.25em; }CSS에 추가 공간으로 페이지 이름을 쓰거나 인터페이스의 나머지 부분을 동일한 방식으로 보기 전에 얼마나 오래 걸리는지 확인합니다.Nardog (대화) 16:27, 2023년 8월 22일 (UTC) 응답 [응답]

많은 다른 편집자들과 저는 한동안 토크 페이지의 간격을 보았습니다.저는 그런 충동이 없고 그런 충동의 증거를 본 적이 없습니다.하늘이 무너진다는 주장은 증거가 필요합니다.Jonesey95 (대화) 2023년 8월 22일 17:38 (UTC) 회신 [회신]

일관성이 고정되어야 한다는 @Jonesey95의 의견에 동의했지만, 그렇지 않으면 저는 신경 쓰지 않습니다.네임스페이스의 전체적인 개념은 미디어위키에서 가장 혼란스러운 것 중 하나입니다.이는 네임스페이스와 제목을 명확하게 구분하기 때문에 개념을 파악하는 데 도움이 됩니다.네, 네임스페이스를 이미 이해했다면 그렇게 타이핑하지 않았을 것이기 때문에 시각적인 간격이 거슬립니다. 하지만 실제로는 문제가 되지 않습니다!대화: 북극곰은 여전히 효과가 있습니다 :) 즉, 저는 팹의 @Nardog와 같은 우려를 공유합니다.T315893#9059239 일관성을 위해 편집자는 콜론 뒤에 공백을 항상 사용할 수 있습니다.어느새 WP에 또 다른 섹션이 추가되었습니다.MOS에 이어 WP도 엄청나게 늘어납니다.AWB는 모든 것을 일관되게 편집합니다.저는 우리 중 누구도 그것을 원하지 않는다고 생각하지만, 또한 그것이 얼마나 문제가 될 것인지를 정말로 말하기에는 너무 이르다고 생각합니다.지금까지 그것은 거의 문제를 일으키지 않은 것으로 보입니다. 그래서 저는 그것이 우리 모두가 시간이 지남에 따라 단순히 익숙해질 변화 중 하나라고 믿게 되었습니다.처음 배치될 때는 여유 공간이 신경 쓰였지만, 금방 극복했고, 지금은 어느 정도 마음에 듭니다.그냥 눈이 더 편해요.

어쨌든, 우리는 필요하다면 사이트 전체의 CSS로 매우 쉽게 오버라이드할 수 있기 때문에, 저는 정말로 걱정하지 않습니다.원한다면 MediaWiki Core로 업스트림하도록 합니다. 그리고 Jonsey95가 언급한 일관성 문제를 해결함으로써 사람들이 어떻게 반응하는지 볼 수 있습니다.모든 네임스페이스와 모든 MediaWiki 설치에 영향을 미치면 문제가 있는지 여부를 확실히 알 수 있습니다.저는 다른 언어의 맞춤법에 대한 문제들을 알고 있지만, 여기서 우리는 영어에 대해서만 토론하고 있습니다. 그것은 그렇게 큰 문제가 되지 않는 것처럼 보입니다.Musik Animal 15:54, 2023년 8월 22일 (UTC) 회신 [답장]

저는 "수많은 WP:모든 것을 일관되게 만들기 위한 AWB 편집"이 정확히 무슨 일이 일어날 것인지, 커뮤니티가 아니라고 말하고 우리가 편집을 다시 되돌려야 한다면 어떻게 될까요?아니면 더 나쁜 것은, RfC가 질질 끌리는 RfC?저는 확실히 편집자의 시간이 그렇게 낭비되는 것을 보고 싶지 않습니다.NL이 제안한 사이트 전체 CSS 편집은 사전 예방적이고 예방적인 방법입니다.Nardog (대화) 2023년 8월 22일 16:25 (UTC) 응답 [응답]

안녕하세요, 기사 D-아라비니톨 2-탈수소효소에서 제가 한 것은 기사 상단에 있는 Orphan 태그를 제거한 것뿐이었는데, 이제 빨간색으로 표시됩니다.

구문 분석 실패(SVG(브라우저 플러그인을 통해 MathML 사용 가능):서버 "http://localhost:6011/en.wikipedia.org/v1/ "에서 잘못된 응답("수학 확장자가 Restbase에 연결할 수 없습니다."): \rightlefttharpoon</ref>

이곳의 기술 전문가가 업데이트/수정을 할 수 있기를 바랍니다. 하지만, 저는 이것을 전에 본 적이 없습니다.JoeNMLC (대화) 2023년 8월 22일 14:47 (UTC) 회신 [회신]

Now는 오류가 없으므로 생략하십시오.JoeNMLC (대화) 2023년 8월 22일 14:48 (UTC) 회신 [회신]

아마도 관련 phab:T343648.이즈노 (대화) 2023년 8월 22일 17:10, UTC 답장 [답장]

이 특정한 경우, 수학은 일반 텍스트(또는 원하는 경우 {{eqm}} 문자 템플릿)로 사용할 수 있는 단일 기호에 대해 오버킬처럼 보입니다.디맥 (대화) 2023년 8월 22일 17:23, UTC 답장 [답장]

Sean Connery의 3년 페이지뷰와 같이 주어진 시간 동안 페이지뷰를 볼 수 있는 훌륭한 도구가 있지만, 예를 들어 기사의 페이지뷰 상위 20일을 볼 수 있는 방법이 있는지 궁금합니다.BD2412T 2023년 8월 23일 01:30 (UTC) 회신 [회신]

안녕 Techie, 이 링크를 확인하세요. 이름, cons No, Map, 선거인단, 현재 MLA 등과 같은 세부 정보가 있는 Infobox를 추가하고 싶습니다. 오토 위키 브라우저에 대한 지식이 있습니다.저는 이 도구를 쉽게 사용할 수 없습니다.사용 가능한 다른 도구/방법을 제안해 주십시오.I John Kennady (대화) 18:58, 2023년 8월 23일 (UTC) 답장 [답장]

연결된 앵커가 존재하지 않기 때문에 찻집 헤더의 "아래로 건너뛰기" 링크(일시적으로 제거됨)가 작동하지 않습니다.하지만 Esolo5002는 잘 작동한다고 말합니다.Edward-Woodrow :) 2023년 8월 23일 21:23 (UTC) 회신 [회신]

@Edward-Woodrow: MDN 상태참고: 또는 빈 조각()href="#"을 사용하여 HTML 사양에 정의된 대로 현재 페이지의 맨 위에 연결할 수 있습니다.어떤 브라우저를 사용하고 있습니까?파이어폭스에서는 잘 작동합니다.

(또한: 분명히 당신은 포맷으로 무언가를 붙여넣을 수 있고 이것은 그것을 위키텍스트로 변환할 것입니다. 멋지네요.)리틀 퍼퍼스 (대화) 2023년 8월 23일 21:33 (UTC) 응답 [응답]

파이어폭스, 그리고 꽤 최근 버전.Edward-Woodrow :) 2023년 8월 23일 21:38 (UTC) 회신 [회신]

아, 위쪽 링크를 보고 있었어요제가 맞는 것을 볼게요.리틀 퍼퍼스 (대화) 2023년 8월 23일 21:39 (UTC) 응답 [응답]

링크가 있는 버전으로 되돌렸습니다.Edward-Woodrow :) 2023년 8월 23일 21:40 (UTC) 회신 [회신]

아니요, 작동하지 않아요#footer-info존재하지 않습니다.Edward-Woodrow :) 2023년 8월 23일 21:41 (UTC) 회신 [회신]

에 대한 링크가 표시됩니다.#footer그것은 나에게 효과가 있다; 뭔가 (아마도 미디어위키)가 추가하는 것처럼 보입니다.<footer id="footer" class="mw-footer" role="contentinfo" >페이지 하단에어떤 피부를 사용하고 있습니까?리틀 퍼퍼스 (대화) 2023년 8월 23일 21:42 (UTC) 응답 [응답]

...아, 그리고 지금 저는 바닥으로 연결된 다른 링크를 보고 있었습니다.리틀 퍼퍼스 (대화) 2023년 8월 23일 21:43 (UTC) 응답 [응답]

모노북.Edward-Woodrow :) 2023년 8월 23일 21:44 (UTC) 회신 [회신]

로 전환하여 기적적으로 문제가 해결되었습니다.Edward-Woodrow :) 2023년 8월 23일 21:46 (UTC) 회신 [회신]

좋아요, 모노북을 제외한 모든 피부에서 효과가 있어요Edward-Woodrow :) 2023년 8월 23일 21:47 (UTC) 회신 [회신]

좋아요, 그럼 아래쪽 링크가 보이는군요#footer,#footer-info,그리고.#skip-to-bottom-anchor그것들은 각각 모든 스킨, Vector(적어도 나도 사용하는 허용 가능한 버전) 및 {{Skip to top and bottom}}에 있는 것으로 보입니다.로 변경하겠습니다.#footer리틀 퍼퍼스 (대화) 2023년 8월 23일 21:49 (UTC) 응답 [응답]

...그리고.#footer미네르바에서는 작동하지 않습니다.리틀 퍼퍼스 (대화) 2023년 8월 23일 21:52 (UTC) 응답 [응답]

{{Skip to Top and Bottom}} 템플릿 자체는<div>a가 있는 요소skip-to-bottom-anchorID. 아이작(talk) 2023년 8월 23일 21:55 (UTC) 회신 [답장]

네, 그리고 찻집은 {{상하로 건너뛰기}}.그래서 제가 생각하기에 가장 좋은 방법은 링크를 제거하는 것입니다. 만약 어떤 인터페이스 편집자가 실수를 하고 싶어하지 않는다면 말이죠.Edward-Woodrow :) 2023년 8월 23일 22:09, UTC 답변 [답장]

피부.	바닥글 정보	바닥글
모노북
벡터 2010
벡터 2022
미네르바
타임리스

(갈등 편집) 진짜로?Edward-Woodrow :) 2023년 8월 23일 22:07, UTC 답변 [답장]

위키백과:찻집은 {{위에서 아래로 건너뛰기}}를(를) 포함하지 않습니다.위키백과:티하우스/헤더는 위키백과에 포함되지 않은 다른 곳에서 사용됩니다.찻집?아이작(talk) 2023년 8월 23일 22:13(UTC) 회신 [답장]

찻집 관련 서브페이지 및 일부 사용자 샌드박스Edward-Woodrow :) 2023년 8월 23일 22:14 (UTC) 회신 [회신]

"최신 질문을 읽으려면 아래로 건너뛰기"는 다른 위치에 적합한 메시지가 아니라고 생각합니다.Wikipedia에 매개 변수를 추가합니다.메시지가 표시되도록 트리거하고 매개 변수 설정만 Wikipedia에 추가하는 찻집/헤더:찻집.아이작(talk) 2023년 8월 23일 22:19(UTC) 회신 [답장]

헤더를 변환된 컨텍스트와 독립적으로 만들기 위해 헤더는 다음과 같은 위치를 지정할 수 있습니다.<div>특정 ID를 가진 페이지 하단의 요소를 사용합니다.그러나 어느 쪽이든, 메시지는 읽어야 할 질문이 있고 아래로 건너뛰는 것이 타당할 때만 표시되어야 합니다.아이작(talk) 2023년 8월 23일 22:31, 답장 [답장]

ID는 페이지 하단에 어떻게 배치됩니까?그냥 찻집 페이지에 그것을 넣는 것이 더 쉽지 않을까요?에드워드-우드로 :) 에드워드-우드로 :) 2023년 8월 23일 (UTC) 22:33, 답장 [회신]

{{Skip to Top and Bottom}} 템플릿과 동일한 방법으로 CSS 스타일 속성을 사용하여 배치합니다.예, 찻집 페이지는 이미 다음을 삽입했습니다.<div>사용할 수 있는 특정 ID를 사용하지만, 이로 인해 헤더는 항상 {{Skip to Top and Bottom}}을(를) 제외한 Teahouse 페이지에 종속됩니다.하지만 헤더가 자신의 대상 ID를 관리하도록 하는 것보다 메시지 표시를 제어하는 것이 더 중요하다고 생각합니다. Isaacl (talk) 22:46, 2023년 8월 23일 (UTC)Reply[회신]

"=<interpace>interval"...와 같은 문자열이 포함된 기사를 검색하려고 합니다. 여기서 "<intervalpace>"는 공백 문자(일반 공백 제외)에 나열된 문자입니다.예를 들어 "얇은 공간"을 찾기 위해 검색 문자열은 무엇입니까?나는 노력했다.insource:/[=](\u2009){1,}http/코드 포인트는 U+2009이고 이 튜토리얼에 따르면 작동할 수 있지만 작동하지 않기 때문입니다.CirrusSearch 문서에는 일부 정보가 있지만 제가 볼 수 있는 것은 아무것도 도움이 되지 않습니다. -- GreenC 01:10, 2023년 8월 24일 (UTC)응답 [응답]

당신은 그곳의 문서에 \u2009가 아닌 실제 유니코드 문자를 사용해 보았습니까?이즈노 (대화) 01:36, 2023년 8월 24일 (UTC) 회신 [답장]

\u... 안 될 거예요."정규 표현식" 구글링 내 문제는 Elastic 검색(CirrusSearch가 백엔드로 사용하는 것)에 매우 제한적인 도움이 됩니다. 사실상 표준인 PCRE 다양한 정규 표현식에 대한 결과를 얻을 수 있으며, Elastic 검색 구현 맛은 훨씬 더 제한적이고 다소 다른 구문을 사용합니다.(업스트림 설명서)이와 같이 문자 그대로의 문자를 검색하면 정확하게 보이는 결과를 얻을 수 있습니다.아니면, 적어도 제가 현장에서 확인한 기사의 출처에는 문자 그대로의 얇은 공간이 있었습니다.(공백 문자도 공백도 없고 공백도 없다는 사실에 놀랐습니다.)—Cryptic 2023년 8월 24일 02:06 (UTC) 회신 [회신]

예: c:카테고리:사용자 BG-3. cat-a-lot이 사용자 페이지를 이동하지 않는 이유를 알 수 없습니다.그것들을 옮길 수 있는 도구가 있습니까?RZuo (대화) 2023년 8월 24일 05:37 (UTC) 응답 [응답]