모듈 토크:사이드바/아카이브 4

Module talk

margin-right: 0.5em을 통해 브라우저가 hlist를 보다 안정적으로 랩핑할 수 있습니다.

브라우저가 h리스트를 보다 안정적으로 랩할 수 있도록 왼쪽+오른쪽 패딩/마진을 늘립니까?

여백-오른쪽:0.5em 왼쪽+오른쪽 패딩/여백을 추가하면 사이드바 내에서 hlists가 랩될 때 오류가 감소하거나 제거되는 것으로 보입니다(예: {{과학 사이드바}}의 최근 역사 참조). 따라서 Lua를 말하는 사람은 이 모듈에 다음과 같은 내용을 추가해 주십시오.Sardanaphalus (토크) 2014년 8월 13일 14:10 (UTC)응답[응답]
추신 위의 내용에서 많은 부분을 해결할 수 있을 것 같습니다.

@ Sardanaphalus:이걸로 뭘 고칠지 모르겠네요어떤 기능을 하는지 나란히 데모를 게시할 수 있습니까?Jackmcbarn (대화) 2014년 8월 13일 (UTC)응답[응답]
  • 이전에 어디에서 결함이 시연되었는지를 찾을 수 없었습니다. 따라서 {{과학의 역사 사이드바}의 일부를 사용한 간단한 예를 소개합니다.
liststyle=list-right:0.5em 미적용;
수학
liststyle=slist-right:0.5em 포함;
수학
이러한 종류의 글리치는, 라인 랩의 장해를 가져오는 회선상의 링크가 굵은 글씨로 되어 있는 경우(이미 존재하지 않는 경우는 없는 경우) 악화될 가능성이 있습니다.Sardanaphalus (대화) 2014년 8월 13일 21:40 (UTC)응답[응답]
이 '글리치'는 보이는 대로이며, 시스템에서 사용되는 글꼴에 전적으로 의존합니다.포장 동작을 '수정'하면 다른 사람의 시스템에서 수정하려는 오류가 발생합니다.따라서 템플릿에 여백이나 패딩을 추가해서 보기 좋게 만들지 마십시오. 대부분의 경우 시스템에서만 작동하기 때문입니다. -- [[User:Edokter]] {{talk}}2014년 8월 14일 (UTC) 09:03 (응답)
  • 현재 PC에서 Windows 7의 Palemoon(Firefox 기반 브라우저)을 사용하고 있으며, Wikipedia, Palemoon, Windows의 폰트 변경이나 커스텀 설정(비표준 줌 설정 등)은 없습니다.이들 지역의 우파 의원들의 약간의 증가가 어떻게 다른 사람들의 시스템에 이런 종류의 오류를 가져올 수 있을까요?? (사이드바 및 인포박스는 요소의 오른쪽 측면에 영향을 주는 여백/패딩 설정을 이미 사용하지 않습니다.?) Sardanaphalus (토크) 2014년 8월 14일 (UTC)응답 [응답]
    • 앞서 말한 바와 같이 사용되는 글꼴이나 렌더링된 요소의 크기 등의 시스템 메트릭에 따라 달라집니다.Hlist 랩핑은 완벽하지 않습니다. 결코 완벽하지 않을 것입니다.다만, 사용의 시스템에 문제가 있는 경우는, 다른 제품에서는 보기에도 좋지 않을 수 있습니다.따라서, 여백이나 패딩으로 포장 문제를 「수정」하지 말아 주세요.다른 정보 상자에서는 Common.css에서 정의된 표준 CSS가 사용되며 인라인 CSS가 거의 없습니다(있는 경우).이 경우 Common.css에서 실행할 수 없는 경우에만 사용됩니다. -- [[User:Edokter]] {{talk}}2014년 8월 14일(UTC) 19:44 (응답)
  • 하지만 이미 사이드바나 인포박스 등은 (Common.css 등의) 여백/패딩 설정을 사용하고 있지 않습니까?Sardanaphalus (토크) 2014년 8월 14일 21:57 (UTC)응답[응답]
Palemoon 브라우저에서는 listtyle/content style을 덮어쓸 필요가 없다고 생각합니다.Windows 7 에서는 파이어폭스, Windows 7 에서는 크롬, Windows 7 에서는 인터넷 익스플로러, Linux 에서는 파이어폭스를 확인했는데, 두 예에서는 차이가 없었습니다.Frietjes (토크) 2014년 8월 18일 (UTC)응답[응답]
  • 그거 재미있네요.제가 오해하지 않도록 하기 위해 위의 "수학" 예에서 목록을 정리하는 방법에 차이가 없으며 링크가 아닌 점으로 시작하는 행도 없습니다. Sardanaphalus (talk) 17:35, 2014년 8월 18일 (UTC)응답
추신 위와 같은 리스트랩 오류가 발생한 적이 있습니까?Sardanaphalus (대화) 2014년 8월 20일 09:26 (UTC)응답[응답]
이상이 보이지 않기 때문에 질문에 어떻게 대답해야 할지 모르겠습니다.문제를 해결하는 데 도움이 필요하면 스크린샷을 업로드해야 합니다.Frietjes (토크) 2014년 8월 23일 15:55 (UTC)응답[응답]
  • 다음은 화면 스크린샷입니다.
Listwrapping comparison (screenshot portion).jpg
Sardanaphalus (대화) 2014년 8월 24일 10:06 (UTC)응답 [응답]
한 줄이 점으로 시작하는 문제가 당신에게 있나요?그렇다면, 패딩/마진을 만지는 것은 완전히 잘못된 수정 방법입니다.Jackmcbarn (대화) 2014년 8월 24일 (UTC)응답[응답]
  • 그런 출력을 방지하기 위해 어떤 것을 만져야 하는지 추천해 주시겠습니까?Sardanaphalus (토크) 2014년 8월 25일 14:59 (UTC)응답[응답]
  • 넌 못 해, 내가 이유를 설명했잖아.수평 리스트가 그 특정 포인트에서 줄바꿈하면 글머리 기호로 다음 행이 될 수 있습니다.이 동작은 [User]에서 보다 명확하게 확인할 수 있습니다.Edokter/sandbox #창 크기 조정 중 랩 테스트. -- [[User:Edokter]] {{talk}}2014년 8월 25일 (UTC) 17:02 (응답)
  • 단어들은 항상 올바르게 포장되어 있는 것처럼 보인다(즉, 각각은 하나의 깨지지 않는 단위로서, 예를 들어 "수학"과 같은 단위가 아니다).
    atics")는 브라우저가 word+nbsp+(bold?)dot의 조합을 마치 단어(즉, 깨지지 않는 단일 단위)인 것처럼 처리하도록 지시되지 않은 것 같습니다.다만, 제가 알기론, nbsp와 (굵은) 도트는 단어 앞 글자와 같은 문자이거나, 혹은 그렇게 취급할 수 있습니다.그래서 문자열이 단어라면 왜 문자열과 2자 이상의 문자가 단어일 수 없는 걸까요?(굵은 글씨 등의 스타일링이 있는 점이라면 캐릭터 취급을 방해합니까?)Sardanaphalus (토크) 2014년 8월 27일 17:23 (UTC)응답[응답]
  • 수평 목록(hlist)이 도입되었을 때 목록 항목은 글머리 기호 등 실제로 랩핑되지 않았습니다.그러나 이로 인해 Internet Explorer에서 원치 않는 동작이 발생하여 다른 브라우저에 다른 버그가 발생하지 않으면 수정할 수 없습니다.날 믿어, 난 그걸 해결하기 위해 몇 달이나 걸렸어.결국 래핑되지 않은 목록 항목은 포기되고 브라우저의 네이티브 래핑 동작에 맡겨졌습니다.hlist는 브라우저의 표준 개념이 아니기 때문에 이에 대한 해결책은 없습니다.기본적으로 브라우저가 일반 텍스트인 것처럼 일반 목록을 표시하도록 속이는 것입니다.HTML의 다음 반복에는 수평 리스트의 네이티브 형식에 대한 사양이 있지만, 래핑을 어떻게 처리하는지 모르겠습니다.그때까지 우리는 우리 자신의 불완전한 버전으로 갚아야 할 것이다. -- [[User:Edokter]] {{talk}}2014년 8월 27일 (UTC) 18:46 (응답)
  • 이제 이 상황을 좀 더 이해하기 시작했다고 생각합니다.감사합니다.상기 내용을 미리 파악하지 못한 점 사과드립니다.하지만 마진/패드를 늘리면 오포장이 줄어들지 않을까요?Sardanaphalus (토크) 00:10, 2014년 9월 1일 (UTC)응답[응답]
    아뇨, 특정한 경우에는 도움이 되겠지만 다른 많은 경우처럼 그들이 문제의 원인이 될 거예요Jackmcbarn (대화) 2014년 9월 1일 01:32 (UTC)응답[응답]

2014년 9월 19일 템플릿 보호 편집 요청

Siddrth.reddy (토크) 2014년 9월 19일 14:00 (UTC)응답[응답]

Red question icon with gradient background.svg 미완료: 어떤 변경을 원하는지 명확하지 않습니다.구체적인 변경 내용은 "X에서 Y로 변경" 형식으로 기재해 주십시오.Jackmcbarn (대화) 2014년 9월 19일 (UTC)응답[응답]

요청 편집(템플릿에 영향을 주는 경우:접을 수 있는 목록이 있는 사이드바

현재 {{Side bar with collapsable lists}}}는 list[N]가 전개되어 표시되어야 하는 경우 expanded와 정확히 일치하도록 list[N]명이 필요하다고 생각합니다.Lua의 노하우를 가진 사람이 이 요건을 대소문자를 구분하지 않도록 할 수 있을까요?특히, 이전에 전달한 템플릿 중 몇 개가 그대로 설정되어 있는 것 같기 때문입니다.- Sardanaphalus (talk) 18:15, 2014년 10월 15 (UTC) 답변

이렇게 하면 소문자를 사용하는 다른 모든 접이식 상자와 일치하지 않습니다.expanded배타적으로또 있다collapsed- 둘 다 페이지 스타일링을 위한 클래스 이름으로 사용되며 스타일시트에서는 클래스 이름이 대소문자를 구분합니다.Internet Explorer에서는 제외됩니다.--Redrose64 (talk) 2014년 10월 15일 (UTC)응답[응답]
Redrose64 질문을 잘못 읽으신 것 같습니다.기본적으로 요청은 이 변경과 동일합니다(읽기 불가능하지만 'lc:'를 검색하십시오).Frietjes (토크) 2014년 10월 15일 21:36 (UTC)응답[응답]
이런 변화라면 충분할 거야Frietjes (토크) 2014년 10월 15일 21:44 (UTC)응답[응답]
@ Sardanaphalus:이러한 변화의 이점은 무엇입니까?Wikitext를 보다 일관되게 만들고 싶습니다.(또한 같은 이유로 네비게이션 바 변경의 그 부분을 취소해야 한다고 생각합니다.)Jackmcbarn (대화) 00:51, 2014년 10월 16일 (UTC)응답[응답]
동의합니다. 일관된 파라미터 규약이 선호되며 모호성이 존재하는 경우에는 전파되지 않아야 합니다. -- [[User:Edokter]] {{talk}}2014년 10월 16일(UTC) 09:09 (응답)
대소문자를 구분하는 것은 적어도 위키피디아의 일부 다른 측면/기능에서는 표준(기존)이 아닌가요?Sardanaphalus (토크) 2014년 10월 16일 (UTC)응답[응답]
아니, 그렇지 않아.템플릿/모듈 파라미터는 항상 대소문자를 구분합니다.파라미터가 대소문자를 구분하지 않는 유일한 경우는 하위 호환성이 (일시적으로) 필요한 경우입니다. -- [[User:Edokter]] {{talk}}2014년 10월 16일 (UTC) 11:59 (응답)
직접적인 이점은 목록 이름이 대소문자를 구분하지 않는 것처럼 설정된 템플릿의 목록 확장 기능이 작동하는 것입니다.더 중요한 것은 (내 생각에) 기능을 사용하려는 사람들에게는 어느 정도 유연성과 만족감을 줄 수 있다는 것입니다.그 목적을 제대로 이해했다면 목록 제목이 지나치게 복잡하거나 망가질 수 있기 때문에 목록 이름을 사용하여 기능을 구현합니다.Sardanaphalus (토크) 2014년 10월 16일 (UTC)응답[응답]
이 변경이나 {{navbox with collapsible groups}}}에 대한 변경에 대한 합의가 없는 것 같으니 Jackmcbarn의 제안대로 일관성을 위해 다시 이 변경과 일치하도록 하겠습니다.Frietjes (토크) 2014년 10월 29일 (UTC)응답[응답]
이 변화에 반대하는 의견의 일치는 어디 있습니까?이상, 답변 없는 오해와 제안이 있는 것 같습니다.예를 들어 {{templatename Sectionname}과(와) {{Templatename sectionname}} 모두 동일한 결과를 얻을 수 있도록 하는 것 외에 다른 방법이 없다는 것은 분명하지 않을 것입니다.Sardanaphalus (대화) 2014년 10월 30일 (UTC)응답[응답]
문제는 이에 대한 명확한 이점은 없지만, 이로 인해 코드가 커지고 복잡해지고 (약간) 느려진다는 것입니다.에독터, 프리제스, 그리고 내가 다 얘기했었지Jackmcbarn (대화) 2014년 10월 30일 (UTC)응답[응답]
분명한 이점은 이 기능을 사용하려는 사람들에게 있습니다. 프로그래머와 같은 사고방식을 가지고 있다고 가정해서는 안 되는 사람들입니다.이러한 문제가 있는 경우('일관성'이 중요한 경우) 템플릿 이름, 기사 이름 등의 사용도 대소문자를 구분해야 합니다(라벨이 아닌 이름).Sardanaphalus (토크) 2014년 10월 31일 00:04 (UTC)응답[응답]
첫 번째 캐릭터만 빼고요.Jackmcbarn (토크) 2014년 10월 31일 02:27 (UTC)응답[응답]
하지만 이 구역 이름들은...?Sardanaphalus (대화) 2014년 10월 31일 09:16 (UTC)응답[응답]
MediaWiki 소프트웨어는 기사, 템플릿 또는 기타 모든 pagename의 첫 글자를 제외하고 대소문자를 구분하지 않습니다.이러한 pagename에 대해 대소문자를 구분하지 않기 위해 리다이렉트를 작성해야 합니다.이러한 소프트웨어에는 속도 위반이 없습니다.
링크의 일부를 형성할 때 섹션 헤딩의 대소문자는 브라우저에 의해 처리되기 때문에 소프트웨어에서는 거의 신경 쓰지 않습니다.대부분의 브라우저는 섹션 링크에서 대소문자를 구분하지만 Internet Explorer는 대소문자를 구분하지 않습니다.
MediaWiki 소프트웨어는 템플릿파라미터의 이름에 대해 대소문자를 구분합니다.이러한 파라미터의 이름을 대문자와 소문자를 구분하기 위해서는 에일리어스를 작성해야 합니다.이에 따라 가능한 모든 치환을 코드화할 필요가 있기 때문에 특히 파라미터 이름이 길수록 템플릿 처리가 느려집니다.예를 들어 템플릿에 전달된 매개 변수가 호출된 경우 ab=템플릿 내에서 다음과 같이 코드화되어 있습니다.{{{ab }}}대소문자를 구분하기 위해서는 다음과 같은 코드가 필요합니다.{{{ab {{{aB {{{Ab {{{AB }}}}}}}}}}}}글자 한 글자 남길 때마다 시험 길이가 두 배로 늘어납니다.
이 소프트웨어는 템플릿 파라미터의 값에도 대소문자를 완전히 구분하지만, 이러한 경우 대소문자를 구분하지 않는 값을 만들기 위한 코드를 추가하는 것은 비교적 쉽습니다.파서는 다음과 같이 작동합니다.{{lc:}}사용할 수 있지만, 이것 역시 처리 시간을 증가시킵니다.이것은 반드시 실장하는 것이 좋은 것은 아닙니다.여러 템플릿이 동일한 목적을 가진 동일한 이름의 파라미터를 가지고 있는 경우, 다른 템플릿과 다른 동작을 할 경우 발생하는 혼란을 피하기 위해 서로 동일한 값을 재인식하는 것이 좋습니다. --Redrose64 (talk) 15:08,2014년 10월 31일 (UTC)응답[응답]
  • "...파서 함수는 다음과 같은 기능을 사용할 수 있지만, 이것도 처리 시간을 증가시킵니다.."
만약에...{{lc:}}너무 많은 시간이나 자원을 필요로 합니다.#if: 등의 다른 기능보다 더 많은 시간을 필요로 하는 경우, 그것은 훨씬 더 큰 부담이 될까요?- 그럼 {{Sidebar with collapsible lists}}(및 {Navbox with collapsible groups}} 등)의 지시에 따라 목록/그룹 이름에만 소문자를 사용하도록 지시할 수 있습니까?그러면 이러한 템플릿의 기능을 사용하려는 사람들이 제목을 복제하는 이름을 사용하는 것이 좋다고 생각할 가능성이 줄어들 것입니다(목록/그룹 제목보다 이름이 사용되는 이유에 대해 관심을 끌 수 있습니다).또는 이러한 축소 가능한 목록/그룹 등을 보다 견고하게 관리하기 위한 다른 방법이 있을 수 있습니다.
피드백 감사합니다. Sardanaphalus (토크) 2014년 11월 1일 22:10 (UTC)응답[응답]
정말 lc는 매우 싸다.템플릿을 용서하는 데 도움이 됩니다.행운을 빈다:리치 팜브러, 2014년 11월 10일 (UTC) 03:11
렌더링 시 약 100만분의 1초입니다.그것은 필요 이상으로 많지만, 여전히 무시할 수 있는 수준입니다.행운을 빈다:리치 팜브러, 2014년 11월 10일 (UTC) 04:03
perl은 5년 된 PC로 150배 정도 빨라...행운을 빈다:리치 팜브러, 2014년 11월 10일 (UTC) 04:21

2014년 10월 31일 템플릿 보호 편집 요청

테이블의 셀스페이스 속성을 적절한 CSS로 대체하십시오.감방 공간을 포함한 구식 속성들이 아직 남아있어요에러 리스트를 봐 주세요.잘 부탁드립니다!Template_talk 참조:자세한 내용은 Infobox#Protected_edit_request_on_30_October_2014를 참조하십시오.Rezonansowy (토크 투고) 2014년 10월 31일 21:17 (UTC)응답[응답]

@Stradivarius씨:수정 부탁드립니다.--Resonansowy (토크 투고) 2014년 11월 11일 11:32 (UTC)응답[응답]
사용되지 않는 Atribute는 다음 두 가지가 있습니다.
  • .attr "cellspacing", args.cellspacing 또는 5)
  • .attr "셀패딩", args.셀패딩 또는 0
-- Gadget850 talk 15:16, 2014년 11월 14일 (UTC)응답[응답]
CSS는 Common.css(아직 존재하지 않는 경우)로 해야 합니다.일반 인라인 CSS는 피해야 합니다. -- [[User:Edokter]] {{talk}}2014년 11월 14일 (UTC) 15:42 (응답)
@Gadget850 및 Edokter:Template와 마찬가지로 구현해야 합니까?Infobox? --Rezonansowy (토크 투고) 2014년 11월 14일 (UTC)응답[응답]
Template talk에서도 비슷한 요청이 있습니다.Navbox#HTML입니다.Edokter가 제안하는 것을 이해하고 싶습니다.유사한 수정사항을 몇 가지 적어두었습니다만, 만약 우리가 이것을 다르게 해야 한다면... -- Gadget850 18:24, 2014년 11월 14일 (UTC)응답[응답 talk]
오래된 Atribute는 그 자체로 교환할 필요가 없습니다.이 Atribute는 오래된 브라우저를 지원하기 위해 사용되었습니다.필요한 CSS는 이미 갖추어져 있다고 생각합니다.제가 지적하고 싶은 것은 삭제된 Atribute를 인라인 CSS로 대체해서는 안 된다는 것입니다.-- [[User:Edokter]] {{talk}}2014년 11월 14일 19:00 (UTC)응답[응답]
어떤 오래된 브라우저?최근 MediaWiki에서 IE 이전 버전에 대한 지원이 중단되었다고 생각합니다. -- Gadget850 talk 19:10, 2014년 11월 14일 (UTC)응답[응답]
아마도 IE6/7에서 '어드밴스드' 테이블 CSS를 이해하지 못했을 것입니다.반드시 'drop support'를 실행한 것은 아닙니다.이러한 브라우저에서는 JavaScript를 실행 중지했습니다.하지만 그건 거의 똑같아... -- [[User:Edokter]] {{talk}}2014년 11월 14일 (UTC) 19:42, 응답[응답]
Wikipedia가 HTML5로 전환한 이후 일부 태그는 더 이상 사용되지 않고 올바르지 않습니다.Village 펌프에 대한 논의를 참조하십시오.이 문제를 해결할 것입니다. --Rezonansowy(talk contributes) 2014년 11월 14일 22:47 (UTC)응답[응답]
그냥 한번 봤는데...모든 CSS는 인라인입니다.그것은 곧 개선될 것입니다.그 사이에 오래된 속성을 제거했습니다. -- [[User:Edokter]] {{talk}}2014년 11월 14일 19:47 (UTC)응답[응답]
@Edokter:현재 템플릿에디터는 이 사용하는 CSS를 변경할 수 있습니다.모든 것이 공통적인 경우 관리자만 할 수 있습니다.모든 것을 공통으로 하기 전에 심각하게 고려해봐야 할 것 같아요.Jackmcbarn (대화) 2014년 11월 14일 (UTC)응답[응답]
그것은 대단한 논쟁은 아니다.Common.css에 공통 CSS를 넣는 것이 일반적입니다.모듈 생성 CSS는 태그가 불가능하여 테스트하기가 매우 어렵습니다.Inline CSS는 Mobile에서도 문제가 발생할 수 있으므로 전체적으로 inline = bad입니다. -- [[User:Edokter]] {{talk}}2014년 11월 14일 21:40 (UTC)응답[응답]
(아직도 Lua를 알아보고 있는 중) 이제 나는 Edokter의 의견에 동의한다.Common.css 업데이트를 받는 것은 그리 어렵지 않습니다 talk. -- Gadget850 22:13, 2014년 11월 14일 (UTC)응답[응답]

"자녀" 취급

안녕하세요 – 코드가 수정되어 처리될 수 있도록 부탁드립니다.{{Sidebar child{{Navbox}}개 핸들로{{Navbox child?
나는 다음과 같은 행이 의심된다.border = trim(args.border or args[1] or '')(모듈에서:Navbox)는 어딘가에 필요하겠지만, Lua를 배우는 대신, 제 추측으로는 그 정도일 것입니다.
Sardanaphalus (대화) 2015년 1월 13일 12:31 (UTC)응답[응답]

추신 {{Infobox}}에도 같은 수정이...?

{{infobox}}이미 이 작업을 수행하고 있습니다. child=yes파라미터. --Redrose64 (talk) 14:27, 2015년 1월 13일 (UTC)응답[응답]
하지만 감당할 수 있을까?{{Infobox child..? Sardanaphalus (대화) 2015년 1월 14일 00:26 (UTC)응답[응답]
아니요, 이름 없는 파라미터는 지원되지 않습니다. -- [[User:Edokter]] {{talk}}2015년 1월 14일 01:14 (UTC)응답[응답]

content Nclass

content1style, content2style 등은 있습니다만, content1class, content2class 등은 없습니다.예를 들어 사이드바의 콘텐츠로 제공되는 리스트가 반드시 모든 "hlist" 또는 모든 "plainlist"는 아니므로 이들 파라미터를 포함할 수 있습니까?Sardanaphalus (대화) 2015년 1월 18일 10:40 (UTC)응답[응답]
(즉, 오른쪽 아래가 아니라 왼쪽 아래와 같은 코드를 사용할 수 있습니다.)

{{사이드바 이름 = ....class = plainlist = heading1 = ....content1 class = hlist content1 = ........heading2 = ....content2 = ........heading3 = ....clist content4 = hlass4 = ........5 heading5 =content5 = ...... (etc) }}
 
{{사이드바 이름= ..클래스=플레인리스트
 
............ 
 
heading1 = ......content1 = {{startflatlist} ......{endflatlist}
 
heading2 = ......content2 = ...... 
 
heading3 = ......content3 = ...... 
 
heading4 = ......content4 = {{startflatlist} ......{endflist}
 
heading5 = ......content5 = ...... 
 
(등)
 
}}
  • listNclass는 {{Sidebar with collapsible lists}}에 사용할 수 있다는 것을 방금 알았습니다만, 위와 같이 대응하는 contentNclass는 {Sidebar}에 사용할 수 없는 것 같습니다.후자를 적절히 조정해 주실 수 있나요?Sardanaphalus (토크) 2015년 1월 26일 23:21 (UTC)응답[응답]

헤더 패딩이 일관되지 않음

예를 들어 대량학살의 차별 사이드바를 참조하십시오.첫 번째 헤더는 적어도 색칠된 부분에 관해서는 두 번째 헤더보다 현저하게 작습니다.누가 이걸 고쳐줄 수 있나요?Kaldari (토크) 2016년 4월 29일 18:40 (UTC)응답[응답]

Kaldari, 문제는 하나는 축소 가능한 목록 제목이고 다른 하나는 머리글이라는 거야.접을 수 있는 목록 제목에는 색칠을 포함한 내부 접을 수 있는 div가 있습니다. 여기서 헤더는 표준 표 머리글만 사용합니다.차이를 보정하기 위해 해크를 추가했지만 접을 수 있는 div 용기가 테이블 셀 전체를 채우는 것이 좋습니다.Frietjes (토크) 2016년 4월 29일 18:58 (UTC)응답[응답]
테이블 셀 컨테이너에서 왼쪽/오른쪽 패딩을 제거하여 고정할 수도 있습니다.Frietjes (토크) 2016년 4월 29일 19:17 (UTC)응답[응답]
저는 어떤 해결책이라도 좋습니다.감사합니다!Kaldari (토크) 2016년 4월 29일 22:11 (UTC)응답[응답]

최신 편집으로 많은 사이드바가 엉망이 되었다

예를 들어, Politics of Angola의 사이드바 여백이 나쁘고 포함된 컨텐츠의 크기가 잘못되었습니다.Frietjes (토크) 2017년 6월 3일 00:17 (UTC)응답[응답]

태그 제거 오류

코드라이크

{{title title = 최상위 제목 1 = {{theading child = yes title = 첫 번째 서브섹션 제목 1 = 1.1 content 1 = 1.1 content } = {theading child = yes title = 두 번째 서브섹션 제목 1 = 2.1 content 2.1 content } = 아래 텍스트 = = = = }

제거 태그 오류가 발생하다<th>모듈 내의 행이 원인일 수 있습니다.다음과 같은 사이드바

: @to do는 mw.disclosed가 취득하면 다시 unclosed로 바꿉니다.

--RolandUnger (토크) 5:55, 2017년 7월 25일 (UTC)응답[응답]

모듈: Infox Image 트래킹

Module에서 로직 중 일부를 Import할 수 있는 방법이 있는지 궁금합니다.InfoxImage를 이 모듈에 입력합니다.특히 카테고리에서 실행되는 추적:미리 보기 이미지가 있는 정보 상자를 사용하는 페이지입니다.카테고리를 취득하는 것은 최고입니다.썸네일 이미지가 있는 사이드바를 사용한 페이지.이 문제에 대해 의견이 있으십니까? --Zackmann08 (/)Talk to meWhat I been doing 16:41, 2017년 9월 19일 (UTC)응답[응답]