위키백과:마을 펌프(제안)/아카이브 176

위키백과 창립 20주년을 기념해 한시적으로 로고를 바꿔야 할까?— Wug·a·po·des 22:40, 2021년 1월 13일 (UTC)[응답]

RfC 형식

짧은 시간 때문에, 이 RfC는 24시간 동안만 실행될 것이다.단축된 시간대에 적정한 참여를 보장하기 위해, 행정고시판, 중앙집중식토론고시, 마을펌프 등에 안내문을 남겨두었다.

원래 RfC에서 제안한 파일:WP20 EnWiki20 SimplifiedLogo.svg.편집자의 관심으로 인해 아래에 다른 옵션이 추가되었으며 문자로 레이블이 지정된다.기본 설정의 순위를 가장 낮게 지정하고, 반대하는 옵션은 나열하지 마십시오.

제안된 이미지

최소 변경 사항

B WMF 캠페인 스타일로

C 위키백과 10 캠페인에 영감을 받아

D WMF 캠페인 스타일의 첫 반복

실행

자세한 내용은 mw:설명서:FAQ#How_do_I_change_the_logo?이상적으로는 서버 관리자가 서버 구성을 업데이트할 수 있지만 MediaWiki에 대한 편집을 통해 변경사항을 달성할 수도 있다.common.css

조사

• 제안자로서의 지원.— Wug·a·po·des 22:40, 2021년 1월 13일 (UTC)[응답]
• 더 이상 머리를 쓰지 마라.레비비치^harass/_hound22:41, 2021년 1월 13일 (UTC)[응답]

  (핑해줘서 고마워, 아자!)그 순서는 A, C, B, D를 선호한다.레비비치 _hound/ 23:22, 2021년 1월 13일 (UTC)[응답]

• 지원하면 안 되는 이유M 임티아즈 (토크 · 기여) 22:52, 2021년 1월 13일 (UTC)[응답]

  A는 나의 투표다.M 임티아즈 (토크 · 기여) 00:06, 2021년 1월 14일 (UTC)[응답]

• 지원, 물론이지, 왜 안 되지?바나몽드 (토크) 22:53, 2021년 1월 13일 (UTC)[응답]

  {{rpp}}}이미지에 대한 이의 없음, D > C > B > A. 바나몽드(토크) 23:28, 2021년 1월 13일 (UTC)[응답]

• 지원 옵션 C, 때가 되었다.세계의 즐거움 — Talk 22:53, 2021년 1월 13일 (UTC)[응답]
• 다른 제안이 없는 경우 조건부 지원^{options since added}.나는 그것보다 더 과감한 것이 더 좋겠지만(그것이 거의 눈에 띄지 않을 것 같음) 아무것도 아닌 것을, 확실히 인수할 것이다.우리 다른 제안 좀 할 수 있을까?{{u Sdkb}} 22:55, 2021년 1월 13일 (UTC)[응답]
• 지원 - 물론이지, 왜 안 되지?비욘드 마이 켄 (토크) 22:56, 2021년 1월 13일 (UTC)[응답]
  • 후속 조치: 이러한 선택 사항 중에서 나는 여전히 원래 게시된 옵션 A를 선호한다.나머지는 너무 야만적이거나 아마추어처럼 보이거나 너무 많은 공간을 차지한다.나는 깨끗하고 직업적으로 보이는 원문의 절제된 표현이 더 좋다.위키피디아는 아마추어 수준을 넘어섰고, 우리는 인터넷 상의 즉각적인 정보의 초기 원천인 지금의 우리 자신을 제시해야 한다.비욘드 마이 켄 (토크) 01:19, 2021년 1월 14일 (UTC)[응답]
• 조건부 지원, Sdkb와 같은 추론.Tayi Arajakate 22:57, 2021년 1월 13일 (UTC)[응답]
• 조건부 지원, Sdkb. davidwr/(talk)/(contracts)/(contracts) 22:58, 2021년 1월 13일 (UTC) 옵션 A는 다른 것들보다 낫지만, 없는 것보다 낫다. davidwr/(talk)/(contracts) 23:28, 2021년 1월 13일 (UTC)[응답]
• 관심이 있으므로 다른 옵션을 설정하는 방법을 참고하십시오.잠깐만.— Wug·a·po·des 23:00, 2021년 1월 13일 (UTC)[응답]
• 지지 A - 나는 그것이 너무 화려하거나 화려하지 않다는 사실을 선호한다.20년 동안 '페디아'를 건설한 멋진 기념일이다.마넷D 토크 23:01, 2021년 1월 13일 (UTC)[응답]
• 지원 만약 우리가 600만개의 기사를 기념했다면, 20년은 왜 안 되었을까?~ HAL333 23:03, 2021년 1월 13일 (UTC)[응답]
• 지원 나는 만화 산 20이 그려진 번쩍이는 위키피디아 로고를 원하며, 배경에는 애니메이션 불꽃(특히 노란색과 빨간색, 녹색은 내 것이 아니다)을 원해.실현. --qedk (t 愛 c) 23:03, 2021년 1월 13일 (UTC)[응답]
• Sdkb당 조건부 지원.요크셔라드 ✿ 23^(talk):04, 2021년 1월 13일 (UTC)[응답]
• 지원 --Enos733 (대화) 23:09, 2021년 1월 13일 (UTC)[응답]

로고 기본 설정은 옵션 A에 이어 옵션 D에 해당된다.기념일을 위해 로고를 변경해야 한다. --Enos733 (토크) 17:58, 2021년 1월 14일 (UTC)[응답]

• Follow up(팔로우업) RfC는 이러한 첫 번째 코멘트 이후 변경되었다.지지를 나타내는 이들은 옵션 A — Wug·a·po·des 23:12, 2021년 1월 13일 (UTC)[응답하라]에만 댓글을 달았다.
• Since we only have 24 hours for the RFC, am pinging the users above who commented before options were added: @Levivich, M Imtiaz, Vanamonde93, Enjoyer of World, Sdkb, Beyond My Ken, Tayi Arajakate, Davidwr, MarnetteD, HAL333, QEDK, YorkshireLad, and Enos733: Aza24 (talk) 23:19, 13 January 2021 (UTC)[reply]
• 옵션 D.가장 생동감이 넘치지만 여전히 프로페셔널해 보인다.{{u Sdkb}}} 23:21, 2021년 1월 13일 (UTC)[응답]
• Sdkb의 경우 옵션 D:활력이 넘치지만 프로페셔널하다.뒤이어:B,C,A.는 거의 눈에 띄지 않는다.B는...괜찮아. 하지만 뭐라고 쓰여있는지 보기엔 좀 힘들어.C는 좀 이상한 것 같다.선장이크 ek 23:26, 2021년 1월 13일 (UTC)[응답]
• 옵션 A는 일관되고 우아한 스타일로 포인트를 만든다.B와 D는 너무 만화적이고 멋있어 보인다.그리고 C는 독자층이 상당히 다를 수 있는 경우, 독자층이 기고자와 같다고 가정하기 때문에 상당히 부정확할 위험이 있다.Andrew🐉 (대화) 23:29, 2021년 1월 13일 (UTC)[응답]
• 옵션 D, B, C, A. A는 너무 미묘해 보이고, C는 어쩌면 네 면면도 너무 미묘해 보인다.고마워, 아자24!요크셔라드 ✿ 23^(talk):31, 2021년 1월 13일 (UTC)[응답]
• 옵션 D.옵션 A도 없는 것보다는 낫다.나는 C에 반대한다 - 그것은 Cards Against Humanity 카드처럼 보인다; 그것은 너무 크고 검은 배경은 좋지 않다.power~enwiki (π, ν) 23:32, 2021년 1월 13일 (UTC)[응답]

벡터의 옵션 D

• 옵션 D: 여기 벡터에 대한 모형이 있다.나는 그것이 너무 바쁘거나 색채가 풍부할 것이라고 생각했지만, 내 생각에 그것은 그것을 맥락에서 본다.다른 20주년 콘텐츠에 적합한 브랜드.두 번째 선택: A, 그 다음 B.C가 아니라, 우리가 뭔가를 항의하는 것 같아. 아니면 누군가가 죽었어.— 이어비히^talk 23:34, 2021년 1월 13일 (UTC)[응답]
  • 재미있는 조롱.혹시 영상과 텍스트의 간격을 조금 더 늘려야 할까?미루는 Reader (대화) 08:09, 2021년 1월 14일 (UTC)[응답]

    그래, 네 말이 맞을지도 몰라.현재의 로고가 어떻게 보이는지, 그리고 "20년 동안"의 중심을 적절히 잡을 수 있는 충분한 공간을 우리에게 줄 수 있도록 조금 더 패드를 붙이시겠습니까?불행히도 시간이 없다.Ping Wugapodes.— 이어비히^talk 19:16, 2021년 1월 14일 (UTC)[응답]

    우리가 말하는 A와 D의 최종 디자인 작업을 한다.UTC 20:00까지 게시해야 함 — Wug·a·po·des 19:48, 2021년 1월 14일(UTC)[응답]

• D C B A ~ ToBeFree (토크) 23:38, 2021년 1월 13일 (UTC)[응답]
• 옵션 B 그럼 D, C, A. B와 D의 디자인이 마음에 드는데 D가 너무 바빠.~ HAL333 23:39, 2021년 1월 13일 (UTC)[응답]

• D 내내 이어위그의 벡터가 내 마음을 바꿨다.~ HAL333 23:44, 2021년 1월 13일 (UTC)[응답]

• 옵션 D – C에 이어, 나는 어떤 WMF 페이지에서 처음 보았을 때부터 D의 스타일을 좋아했다. 다른 사람들이 그렇게 하지 않을까 걱정하면서 관심을 끌어야 한다.A와 B는 기념일이나 기념일이라기엔 너무 싱거워 보인다.아자24 (대화) 23:40, 2021년 1월 13일 (UTC)[응답]
• 옵션 A: 아마도 옵션 B.C는 끔찍하다.D가 지저분하다 — 고스트인The Machine 23:43, 2021년 1월 13일 (UTC)[응답]
• 옵션 C, 비정통적인 의견 확실해네 얼굴에서, 그래.그러나 그것은 누구나 기고가 될 수 있다는 사실에 주목하게 한다. 그것은 우리가 더 많은 인식을 필요로 하는 것이고 나는 그것의 미학을 좋아한다.타이이 아라자카테 23:50, 2021년 1월 13일 (UTC)[응답]
• 옵션 A 또는 C, 만만한 B 또는 D. --에어랜드(토크) 23:52, 2021년 1월 13일(UTC)[응답]
• A, 그 다음 D.B나 C가 아님 — xaosflux 00:05, 2021년 1월 14일 (UTC)[응답]
• 옵션 D -FASTYLY 00:25, 2021년 1월 14일(UTC)[응답]
• 옵션 D를 선택한 다음 옵션 A를 선택하십시오.하지만 로고가 언급할 수 있을지 궁금해서 편집이 10억 건에 달했다."20년, 10억 편집"은 훨씬 더 거창하게 들린다.오비너스 (토크) 00:30, 2021년 1월 14일 (UTC)[응답]
• A, C를 선호하지만 아무 것도 하지 않는 것보다는 이 중 어느 것이든 좋다.-gadfium 00:37, 2021년 1월 14일(UTC)[응답]
• 옵션 D(그 다음 A).나는 이 일을 언제까지나 하고 싶지는 않지만, 하루 동안은 근사하고 펀치(하지만 친근함)가 좋다.--엘미대(토크·기여) 00:40, 2021년 1월 14일 (UTC)[응답]
• 오비누스가 제안한 "20년, 10억 편집" 캡틴이 정말 마음에 든다.이크 ek 01:10, 2021년 1월 14일 (UTC)[응답]

포토샵 기술을 가진 누군가가 확실한 선두주자 옵션 D를 수정하여 작품 아래에 그것을 읽을 수 있을까?~ HAL333

여기 옵션 A를 위한 것인데, 나는 위키백과 부분이 조금 더 늘어날 수 있다고 생각한다.오비너스 (토크) 02:35, 2021년 1월 14일 (UTC)[응답]

나는 지금 잉크케이프와는 멀리 떨어져 있지만, 만약 우리가 20년과 10억의 편집을 모두 가질 예정이라면, 나는 그것들이 끝나기 보다는 위키피디아 텍스트 마크 밑에 들어가기를 권하고 싶다.본질적으로, "자유 백과사전" 부분을 "위키피디아\n20년, 10억 편집"과 같은 것으로 다시 만드는 것이다.또 다른 옵션은 "20년 이상"을 기준치 이상으로 유지하고 아래의 "100억 이상 편집"을 작은 상한으로 하는 것이다.— Wug·a·po·des 02:46, 2021년 1월 14일 (UTC)[응답]

좋은 생각이야!나는 그래픽 디자인에 배경이 없어서 간격이 최적이 아닐 수도 있지만, 비슷한 것을 오른쪽에 붙였다.아마도 누군가가 "자유 백과사전" 글꼴을 사용하여 하나를 만들 수 있을 것이다.오비너스 (토크) 03:02, 2021년 1월 14일 (UTC)[응답]

우가포드의 제안, 대략.

"위키피디아" 위의 텍스트를 가지고 있는 것이 훨씬 더 좋아 보인다.~ HAL333 03:18, 2021년 1월 14일 (UTC)[응답]

나는 문자표를 조롱했다.바로 여기야.이것은 C를 제외한 로고가 선택되는 모든 로고에 넣을 수 있지만, 어쨌든 그것은 가능성이 희박하다.— Wug·a·po·des 04:23, 2021년 1월 14일 (UTC)[응답]

위키백과 20억번째 편집을 기념하는 텍스트 표시

• A 또는 C를 지지하십시오. A를 선호하십시오.B 옵션에는 넘어진 5처럼 보이는 엽기적인 숫자 '2'가 있다.B와 D 옵션 모두 위키백과나 다른 위키미디어 프로젝트와는 전혀 어울리지 않기 때문에 도처에 완전한 리브랜드를 하지 않는 한 너무 이상하다.– Jonsey95 (대화) 01:13, 2021년 1월 14일 (UTC)[응답]
• D > C > A > B > 아무것도. – Teratix ₵ 01:20, 2021년 1월 14일 (UTC)[응답]
• D, C: 현재 D를 지원하고 있으며, C가 근소한 차이로 2위를 달리고 있다.C는 전할 최고의 메시지를 가지고 있고, 그것은 정말 품위 있어 보이지만, 너무 엄숙하다 - 아마도 최근에 죽은 사람을 위한 추모의 깃발처럼 보이지 않게 하기 위해 검은 배경에 50%의 불투명 글리프 또는 색의 얼룩을 가지고 있을 것이다.빌헬름 텔 DCCXLVI 01:32, 2021년 1월 14일 (UTC)[응답]

논평: 오비누스가 제안한 것처럼, 우리는 10억 개의 편집에 대한 것을 언급해야 한다.어떻게 안 할 수 있지?다른 어떤 것 못지않게 대단한 이정표인데, 10억 번째 편집자 자체가 어떤 반달이라기보다는 아만티오 디 니콜라오 경에 의한 것이었다...빌헬름 텔 DCCXLVI 02:12, 2021년 1월 14일 (UTC)[응답]

• A 또는 D를 지원하십시오.나의 유일한 강한 반대는 옵션 C에 대한 것인데, 그것은 너무 크고 파괴적일 수 있다.만약 우리 모두가 동의할 수 없다면, 나는 A로 가는 것을 제안한다. 왜냐하면 그것은 매우 미미하기 때문에 많은 사람들이 눈치채지 못할 것이기 때문이다.20년은 긴 시간이다...이 이정표를 어떤 식으로든 광고해야 할 것 같아! — 2021년 1월 14일(UTC) 뮤지크애니멀 01:56[응답]
• A'를 지지하다.그렇다, 20년은 인정해야 할 벤치마크지만, 나는 세계사에서 지금 이 순간 극적인 축하의 변화가 적절하다고 생각하지 않는다.컬런³²⁸ 2021년 1월 14일 02:30 (UTC) 토론하자[응답하라]

축하하는 것은 재미있고, 전 세계가 매일 더 밝게 보이기 시작한다.백신이 나왔고 경제가 서서히 회복세를 보이기 시작했다.우수성을 추구하는 20년, 편집 10억년은 분명히 축하를 필요로 한다.빌헬름 텔 DCCXLVI 05:01, 2021년 1월 14일 (UTC)[응답]

• 일반적으로 첫 번째 선택은 옵션 A, 두 번째 선택 옵션 D가 지원된다.그러나 제시된 다른 옵션에는 이의가 없다.BD2412 T 02:59, 2021년 1월 14일 (UTC)[응답]
• A는 괜찮지만 D를 지지하십시오.나는 또한 20년 동안 10억의 수정 단어들을 지지한다.다른 두 사람과는 반대야.Best, Barkeep49 (대화) 03:19, 2021년 1월 14일 (UTC)[응답]
• 지지 A, 여기서는 미니멀리즘이 최선이다. - 부시 레인저 03:40, 2021년 1월 14일 (UTC)[응답]
• 부시 관리인 A를 지지하십시오.물론 10억 개에 대한 언급도 지지한다.더블 샤프(토크) 04:16, 2021년 1월 14일 (UTC)[응답]
• A 또는 D에 대한 지원.▲1997kB (대화) 04:56, 2021년 1월 14일 (UTC)[응답]
• 첫 번째 선택은 우가포드의 제안, 두 번째는 옵션 A, 세 번째는 옵션 D와 B. --판다케콕9 (토크) 05:02, 2021년 1월 14일 (UTC)[응답]
• 지지 D 휴게소 보기.B와 C를 반대한다.A는 너무 싱거워 보여 tbh도 눈에 띄지 않을 것 같다.D는 흥분되지만 지저분하지는 않다.미루는 Reader (대화) 05:55, 2021년 1월 14일 (UTC)[응답]
• 처음에는 너무 지저분할 줄 알았지만 벡터에서는 멋져 보이는 지원 D.A을(를) 백업으로.Vaticidalpropet (대화) 05:58, 2021년 1월 14일 (UTC)[응답]
• 지원 D에 이어 A에 이어_signed, 로스길 06:00, 2021년 1월 14일 (UTC)[응답]
• 서포트 A D에 이어 D A.또한 20년 10억의 Asartea 07 ^Contribs:51, 2021년 1월 14일(UTC) 수정 문구 지원[응답]
• 아무거나 지원하라: A, B, C, D. 그냥 어떻게 좀 해봐.GenQuest 07:59, 2021년 1월 14일 (UTC)[응답]
• 아무거나 지원하되 A는 첫 번째 선택으로. -- 한 미치광이(채널 2) 08:11, 2021년 1월 14일 (UTC)[응답]
• 지원 옵션 D —DJ (대화 및 기여) 09:06, 2021년 1월 14일 (UTC)[응답]
• 설명:나는 많은 옵션 A!voters가 그 변화가 얼마나 미묘할지를 놓치고 있다고 생각한다.당신이 알고 있는 토론의 맥락에서 그것을 지나치게 크게 보는 것과 완전히 관련이 없는 것을 위해 위키피디아를 검색하는 것은 별개의 일이다.만약 우리가 우리 자신 이외의 누군가가 (그리고 나는 우리가 이렇게 의미 있는 기념일을 위해 한다고 생각한다) 알아차리기를 원한다면, 우리는 더 과감한 선택을 해야 한다.{{u Sdkb}}} 09:30, 2021년 1월 14일 (UTC)[응답]
• 지지 C에 이어 A A As C가 많은 사랑을 받고 있는 것 같지 않은데, 만약 그것이 이기지 못한다면 A를 나의 투표로 생각해줘.나는 비카투니 옵션을 선호한다. 20년 안에 위키피디아가 성인화 단계에 접어들었다;) 노즈백베어 (토크) 10:18, 2021년 1월 14일 (UTC)[응답]
• 지원 D, 그 다음 A.D는 꽤 멋져 보인다.마리오점프83! 2021년 1월 14일 11시 16분 (UTC)[응답]
• 지원 D, 그 다음 A.Jr8825 • Talk 11:31, 2021년 1월 14일 (UTC)[응답]
• 지지하다.선호: D 또는 B.A는 놓치기 너무 쉽다.– 조 (대화) 11시 59분, 2021년 1월 14일 (UTC)[응답]
• 서포트 A D는 좀 어수선하고 만화가 되어 보이고, A. B는 좀 더 단순하고 미니멀한 형태가 못생겨 보이고, C는 그냥 텍스트가 되는 것이 좋다.
• 지원 A가 가장 전문적으로 보이는..메인페이지의 만화나 그 문제에 대한 어떤 페이지에서도 아이를 멀리하자.--Moxy 🍁 14:20, 2021년 1월 14일 (UTC)[응답]
• 내 생각에 지원 D 옵션 D는 다른 것보다 더 멋져 보인다.댄라우드 (대화) 15:03, 2021년 1월 14일 (UTC)[응답]
• A를 지원하되, 일시적이어서는 안 되지만, 몇 주 동안 메인 로고에 대한 대체 로고가 되어야 한다...IMO--Ozzie10aaa (대화) 16:38, 2021년 1월 14일 (UTC)[응답]
• 지원 D - 다른 옵션과 비교했을 때, 실제로 축하를 느낀다.D는 거리의 활기찬 벽화를 연상시킨다.알타멜 (대화) 16:51, 2021년 1월 14일 (UTC)[응답]
• 서포트 A, C – B, D는 아마추어처럼 보인다.dhtwiki (대화) 19:47, 2021년 1월 14일 (UTC)[응답하라]
• 제안서 중 하나를 선택하는 것을 강력히 지지하며(현재 의견 일치가 있는 것 같기는 하지만) C, D, B, A 순으로 했으면 한다.C는 단순하지만 생각을 불러일으키며 사람들에게 참여에 대해 생각하게 할 수 있다. D는 아름다우며 사람들이 위키피디아를 어떻게 사용하는지, 그리고 왜, B는 멋져 보이고 관심을 끌며, A는 우리가 과거에 사용했던 배너 테마와 비슷하고 논란의 여지가 없다.— 빌로프 (대화) 19:56, 2021년 1월 14일 (UTC)[응답]

  단지 강조하자면, 그것은 A에 대한 D의 강력한 지지다.1 bn 편집도 언급하는 것을 지지한다.— 빌로프 (대화) 22:04, 2021년 1월 14일 (UTC)[응답]

• 나는 그 순서대로 C, D, B, A를 지지한다.우리는 논란의 여지가 없을 정도로 덜 중요한 이벤트들을 위해 더 과감한 로고를 해왔고, 나는 C가 WP 20에게 정말 잘 어울린다고 생각한다. 베스트, 케빈L (L235 · t · c의 알트) 20:22, 2021년 1월 14일 (UTC)[응답]
• 반대하지만, 만약 반대한다면, A는 괜찮아 보인다.'자유 백과사전' 부분을 잊지 말고 보관해라.고마워요.마이크 필 (토크) 20:27, 2021년 1월 14일 (UTC)[응답]
• 나는 이 모든 것이 몇 주 전에 논의되고 기각되었다고 생각했다.마이크 필의 말에 동의해, 변화를 반대하지만, 변화가 있으려면 A가 가장 좋아 보여.--위활트 (대화) 20:43, 2021년 1월 14일 (UTC)[응답]
• A. 나머지 두 사람에 대한 전문성이 부족하다는 데 동의했다.특히 이 일을 하루보다 더 오래 방치할 경우. --Izno (대화) 20:44, 2021년 1월 14일 (UTC)[응답]
• 아무거나 지지하십시오.이것은 알아볼 만한 이정표다.나는 또한 로고의 일부로서 "10억 편집" 메시지를 지지할 것이다.—피톤코더(토크 기여) 21:23, 2021년 1월 14일 (UTC)[응답]
• 제안서 지원:특별히 투표하지 않는 것.Pythoncoder처럼 나도 일반적으로 그 제안을 방해한다.해보자. --Titodutta (대화) 22:16, 2021년 1월 14일 (UTC)[응답]

위에서는 메인 페이지에 배너를 두고 편집에 대한 추가 정보와 격려가 담긴 페이지를 만드는 것에 대해 논의한다.나는 그것이 어떻게 보일 수 있는지 대략적인 모의실험을 해 보았다.폭이 제대로 작동하려면 기술적인 주의가 좀 필요한데, 좀 더 정제된 것이 없어서 미안한데, 지금 너무 짧은 시간대에 있어서 여기에 내놓고 싶다.메인 페이지는 이와 같은 배너를 추가하기 위해 변경될 것이며, 이것은 비디오와 함께 이 페이지와 더 많은 읽기/학습 연결로 이어질 것이다(또한, 아직 몇 가지 기술적인 수정이 필요하며, 채택될 경우 위키피디아:20주년 기념으로 이동될 것이다).이런 일을 하는 것에 대한 일반적인 지지가 있는가?{{u Sdkb}}15:22, 2021년 1월 14일 (UTC)[응답]

나는 배너가 너무 커서 6MM 기사에 대해 했던 것처럼 덜 거슬리는 것을 선호한다고 생각한다(예:또한 페이지 맨 위에 뉴욕 지역을 위한 거대한 CN 배너가 이미 있으며 위키피디아에 게시되어 있음을 기억하십시오.Meetup/NYC/Wikipedia_Day_2021. — xaosflux^Talk 15:48, 2021년 1월 14일(UTC)[응답]

Xaosflux, 배너는 약간 작을 수 있지만, 이것은 위키백과의 20주년 기념일이고, 나는 큰 무언가가 2021년 1월 14일 Asartea 15 ^Contribs:52, (UTC)[응답]이 적절할 것이라고 생각한다.

@Asartea:나는 이것이 이미 로고를 특별하게 스타일링하는 것 외에 더해질 것이라고 추측하고 있다. 그래서 나는 로고를 더 크게 만들지 말 것을 제안하는 것이다.— Xaosflux 16:06, 2021년 1월 14일 (UTC)[응답]

메인 페이지 배너 및 Asartea 15 ^Contribs:53, 2021년 1월 14일(UTC) 페이지 지원[응답]

지원 좋은 아이디어 ....위와 같은 옵션을 몇 개 더 통합할 수 있을까?만화가 유행하는 세계 만화가 유행하는 동안 순탄치 않은 표정인지 확실하지 않다.내 생각에는 좀 더 학구적으로 보여야 할 것 같아.--Moxy: 16:01, 2021년 1월 14일 (UTC)[응답하라]

Moxy, 내가 로고를 빨리 읽는 것을 고려하면 D가 이 배너를 이길 것이라는 것을 암시하는 것 같다.더 많은 학문적 배너와 로고가 충돌할 수도 있다.Asartea 16 ^Contribs:08, 2021년 1월 14일 (UTC)[응답]

D가 이긴다는 데 동의한다....내 손녀딸들의 스티커처럼 생긴 것이 슬픈 얼굴을 모니터한다.색상 블라인드 친화 버전이라도 구할 수 있을까?--Moxy 🍁 00:08, 2021년 1월 15일 (UTC)[응답]

• 참고: 일반적인 WMF 모금 감사 캠페인 대신 WP20을 지원하는 배너 캠페인이 계획되어 있으며, 이전 주요 기념일에 진행되었던 것과 유사한 형식을 따를 것이다.Seddon 18:21, 2021년 1월 14일 (UTC)[응답]

Seddon, 알고 보니 좋네.내일 출시를 계획하지 않는 한 이 일에 방해가 될지는 잘 모르겠다.모금과 편집자 모집의 목적도 다르다.{{u Sdkb}}} 18:32, 2021년 1월 14일 (UTC)[응답]

• 지원 ~ HAL333 19:37, 2021년 1월 14일 (UTC)[응답]
• 나는 제안된 배너를 지지하지 않는다.나는 6m의 기사처럼 우리의 평상시 배너를 지지한다."위키피디아가 10억 편집으로 20번째 생일을 맞이한다"거나 하는 것. --Izno (토크) 20:46, 2021년 1월 14일 (UTC)[응답하라]

  나는 이즈노의 말에 동의해, 백만번째 기사 기념행사에서처럼 일반적인 메인 페이지 배너 스타일을 하자.Mz7 (대화) 23:18, 2021년 1월 14일 (UTC)[응답]

  없는 것보다는 낫다고 생각한다는 말로 분명히 밝혀야 하고, 그저 평범한 배너 스타일을 선호할 뿐, 배너가 있는 것을 아예 막고 싶지는 않다.Mz7 (대화) 00:00, 2021년 1월 15일 (UTC)[응답]

• 지원, 배너가 아니라 페이지 아이콘이 있는 게 좀 이상하다.이것의 형식에 대해서, 나는 무엇이 적절한지 잘 모르지만 그래픽 스타일의 형식을 지지한다.

✨ 에드 토크!✨ 23:48, 2021년 1월 14일 (UTC)[응답]

• 아무것도 아닌 것에 대해 "뭔가" 하는 것에 대한 저항이 지금까지 가장 적은 것 같다. 템플릿에서 스타일링을 벗어남.Main_Page_banner - 특정 랜딩 페이지가 있는 굵은 콜 투 액션(call to action)을 포함한 몇 가지 텍스트로 합의할 수 있는가?— Xaosflux 00:57, 2021년 1월 15일 (UTC)[응답]

• Xaosflux, "x백만 기사" 메시지의 수정 버전을 사용하는 것이 가장 간단한가?예를 들어. 영어 위키피디아가 20번째 생일을 맞이하고 있다! 백과사전의 지속적인 개선에 참여할 수 있는 방법을 알아보십시오.샘-2727 (대화) 01:07, 2021년 1월 15일 (UTC)[응답]

• 템플릿을 통해 일반 배너를 추가했다.메인 페이지 배너, 랜딩 페이지는 위키백과:20주년 기념.나는 적어도 이 선호에 약간은 관여하고 있지만, 처음에는 "아무것도 없는 것보다는 낫다"는 신중해 보이는 것 같다 - 배너에 대한 추가 개선 논의는 여기서 계속하는 것보다 더 환영할 만하며, 만약 그들이 이것이 더 많은 논의 없이 어긋난다고 생각한다면 어떤 관리도 나를 되돌리는 것을 환영할 것이다.— Xaosflux^Talk 02:33, 2021년 1월 15일 (UTC)[응답]

  Xaosflux, 우리가 뭔가를 할 수 있어서 기뻐.하지만 내가 위에서 언급한 기술적인 문제는 아무도 다루지 않았기 때문에, 그것은 현재 특이한 해상도로 모바일이나 스크린에서 형편없이 작동한다.가능한 한 빨리 CSS에 능숙한 사람을 시켜서 그런 것들을 처리하게 할 수 있을까?{{u Sdkb}}}^talk 12:33, 2021년 1월 15일 (UTC)[응답]

  @Sdkb:좀 더 구체적으로 말해줄래?배너에는 적어도 다른 페이지 내용 못지않게 벡터/모노북/미네르바/시간 없는 매우 작고 큰 해상도로 모바일 사이트(en.m.wikipeida)의 미네르바를 통해 내게 표시되는 것 같다.현수막 그 자체를 말하는 것인가, 아니면 랜딩 페이지(위키피디아:20주년) 그 자체를 말하는 것인가(나는 분명히 어떤 작품을 쓸 수 있다고 생각하지만 나는 그 페이지와 아무런 관련이 없었다.— Xaosflux^Talk 18:02, 2021년 1월 15일 (UTC)[응답]

  Xaosflux, 나는 랜딩 페이지를 언급하고 있었다.브랜던XLF가 급습하여 문제를 해결하였으므로, 우리는 지금 준비가 되었다. (그가 모바일용 CSS 문제를 해결하는데 도움을 준 것은 처음이 아니다. 대단히 감사하다!){{u Sdkb}}} 18:05, 2021년 1월 15일 (UTC)[응답]

현재 현수막의 본문은 영어 위키피디아가 20번째 생일을 맞이하고 있다고 말한다.위키피디아 20주년 기념으로 바꿔야 할 것 같아!영어 위키백과와 위키백과의 창간도 마찬가지였고, 위키백과 전체를 창간하는 것이 더 큰 행사인 만큼 이를 축하하는 것이다.게다가 더 깨끗할 뿐이지.그리고 나는 이 배너가 이미 위키백과에 위키링크를 포함하고 있는 영구 배너 바로 아래에 나타날 때 위키링크는 필요하지 않다고 생각한다.{{u Sdkb}} 12:42, 2021년 1월 15일 (UTC)[응답]

Xaosflux, 당신이 실행한 이후로 이 문제에 대해 당신에게 예의주시하고 있다. 당신은 언어를 바꿀 의향이 있는가?{{u Sdkb}}}^talk 18:07, 2021년 1월 15일 (UTC)[응답]

다듬기 완료 템플릿:기본 페이지 배너.— Xaosflux 18:15, 2021년 1월 15일 (UTC)[응답]

로그아웃된 페이지에 가면 WMF 페이지로 연결되는 다소 어리석은 20년 기념이라는 꼬리표가 붙은 현수막을 보게 된다.메타에는 아무 것도 없는 것 같다.센트럴 노티스, 이게 어디서 왔는지 아는 사람 있어?{{u Sdkb}}{{u Sdkb}} 01:07, 2021년 1월 16일 (UTC)[응답]

@Sdkb: 그건 안 보이는데, "20년을 만들어줘서 고마워..기초 사이트에 자바스크립트 이스트레그(syg....)가 있는 ". 지금 보고 있는 요소를 검사하여 더 많은 정보를 제공할 수 있는가?이것도 데스크톱, 모바일, 모바일 앱에 있는 거야?— Xaosflux^Talk 01:55, 2021년 1월 16일 (UTC)[응답]

@Sdkb: 좋아, CN에서도 나오는 것 같군(예: 메타:MediaWiki:Centralnotice-템플릿-WP20 test1 Cake20 I see the text) - 이 모든 것이 사용자에 의해 관리되고 있다고 생각함:Seddon (WMF). — xaosflux 02:02, 2021년 1월 16일 (UTC)[응답]

내가 원래 보고 있던 변종

변경된(전류) 변종

Xaosflux, 내가 방금 페이지를 다시 로드하려고 했을 때, 텍스트가 바뀌어서 지금 우리는 같은 것을 보고 있다.스크린샷 부착.소스 코드에 대해 알고 싶은 것이 있으면 요소 검사 시 무엇을 찾아야 하는지 말만 하십시오.

주요 이슈는 이것들이 메인 페이지에 있는 우리의 배너를 복제하여 약간의 중복성을 만든다는 것이다.매우 긴급한 문제는 아니지만, 완전히 이상적이지는 않다.{{u Sdkb}}{{^talku Sdkb}} 02:09, 2021년 1월 16일 (UTC)[응답]

@Sdkb: 그들은 순환할 CN이 몇 개 있고, 또한 그들이 항상 보여주지 못하게 하는 인상적인 식단을 가지고 있다고 생각한다. 그리고 그들은 단지 MP만이 아니라 모든 페이지에 보여진다 - 그것 때문에 우리의 MP 배너를 제거해야 한다고 생각하지 않는다.— Xaosflux^Talk 02:13, 2021년 1월 16일 (UTC)[응답]

응, 괜찮은 것 같아.중복을 없애기 위해 메인페이지의 CN 배너를 억압하는 것이 좋을지도 모르지만, 나는 강한 느낌이 들지 않는다.{{u Sdkb}}{{u Sdkb}} 02:21, 2021년 1월 16일 (UTC)[응답]

이러한 배너는 실제로 장기간으로 설계되지 않았으며, 조만간 더욱 미묘한 사이트 로고로 변경될 때 (A)를 철회하거나 (B) 표준 사이트 로고로 되돌릴 때 (B)를 철회할 것을 제안한다.어떤 감정이라도 있어?— Xaosflux 19:48, 2021년 1월 20일 (UTC)[응답]

이의 제기를 제외하고 A가 발생할 때마다 이 문제를 해결하겠다(진행은 다른 섹션 참조).— Xaosflux 11:20, 2021년 1월 22일 (UTC)[응답]

템플릿에서 제거됨:기본 페이지 배너.—xaosflux 16:21, 2021년 1월 22일 (UTC)[응답]

• @Mz7:끝내줘서 고마워.선호하는 기간에 대한 결론이 있는가?위에서는 그것이 하루보다 더 길기를 바라는 욕망이 있는 것 같지만, 정확히 얼마나 길어야 하는지에 대해서는 확고한 합의가 이루어지지 않고 있다.{{u Sdkb}}^talk 22:37, 2021년 1월 14일 (UTC)[응답]

  @Sdkb: 불행히도 위의 논의는 어떤 로고를 사용할 것인가에만 초점을 맞추었기 때문에 선호하는 기간에 대한 결론은 없다.나는 "당신이 옳다고 생각하는 것을 하라"고 말하고 싶지만, 만약 당신이 결정적인 대답을 원한다면, 더 많은 논의가 필요하다.Mz7 (대화) 22:40, 2021년 1월 14일 (UTC)[응답]

  I was expecting we might have another "24-hour RfC" on when to remove when it seemed the mood was for changing it back, but perhaps starting an RfC now on duration might be best, closing ad hoc when it's been almost the period of time that has the most agreement. (I'd like a week but I am but one mortal.) — Bilorv (talk) 22:47, 14 January 2021 (UTC)[답장]

• FYI, 우리의 정상적인 배치 절차에 따르면, 빠르면 화요일까지 배치가 있을 수 없다. (월요일은 미국의 공휴일이라 주변에 사람이 거의 없다.)Jdforrester (WMF) (대화) 23:26, 2021년 1월 14일 (UTC)[응답]
• 이런 일이 그렇게 자주 있는 것은 아니니, 나는 한 달까지는 아무 일이나 할 수 있다.— Xaosflux 00:54, 2021년 1월 15일 (UTC)[응답]
• 2주가 적당할 것 같다.~ HAL333 01:26, 2021년 1월 15일 (UTC)[응답]
  • 나는 또한 훨씬 더 긴 기간(최대 1년) 동안 옵션 A를 사용하는 것을 지지한다.충분히 미묘하다.~ HAL333 02:54, 2021년 1월 16일 (UTC)[응답]
• 한 달은 특별한 업적이므로 아마도 1년 동안 이 상태로 있어야 할 것이다(그러나 나는 옵션 A로 바꿀 것이다)--Ozzie10aaa (토크) 02:22, 2021년 1월 15일 (UTC)[응답]
• 오리지널 로고의 변형으로 바뀌지 않는 한 15일을 넘어서는 안 된다.위키미디아가 고른 것이든 위키피디아 브랜드와 거의 어울리지 않는, 숨막히게 촌스러운 로고를 설치한 RfC가 있었다.니흘러스 02:24, 2021년 1월 15일 (UTC)[응답]
• 2주에서 1개월까지는 적당할 것 같다.나는 24시간을 절대 반대한다.오하나^{Talk page} 유나이티드 03:00 2021년 1월 15일 (UTC)[응답]
• IMHO, 현재의 로고(옵션 D)는 한 달 내내 사용하기에는 너무 산만하고 시끄럽다.한편, 처음 24시간 이후에 보다 미묘한 옵션(예: 옵션 A) 중 하나를 사용했다면 한 달 내내 로고를 올려도 괜찮을 것이다. 72.209.60.95 (대화) 03:15, 2021년 1월 15일 (UTC)[응답]
• 현재의 로고(D)가 장기간 사용하기에 적합하지 않다는 위의 IP와, 15일(또는 곧)이 충분히 길어질 것이라는 니흘루스의 의견에 동의한다.두 번 또는 한 달은 너무 길다.2021년 남은 기간 동안 옵션 A(원래 선택)를 교체하는 것은 반대하지 않지만, 일반 로고와는 조금 다른 조정 사항이기 때문이다.그리고 나서 우리는 2022년에 보통 로고로 돌아가곤 했다.비욘드 마이 켄 (토크) 04:31, 2021년 1월 15일 (UTC)[응답]
• 나는 약간 과격한 제안이 있다. 옵션 D를 3일에서 1주일 사이에 유지하고, 옵션 A를 2022년 1월 15일까지 1년 동안 유지하라.빌헬름 텔 DCCXLVI 04:52, 2021년 1월 15일 (UTC)[응답]
• 옵션 D가 옵션 A보다 훨씬 멋있기 때문에 나는 옵션 D, 그 다음 옵션 A를 순서대로 선호했지만, 나는 그것이 얼마나 추한지 오늘까지 깨닫지 못했다.나는 옵션 D가 잠시 사용되어야 하고, 그 후 2022년까지 남은 기간 동안 옵션 A가 사용되어야 한다는 것에 동의한다.마리오점프83! 2021년 1월 15일 04:57 (UTC)[응답]

• 20년 동안 20일 동안.Brightgalrs (/braɪtˈɡl.ərˌs/)^[ᴛ] 05:02, 2021년 1월 15일 (UTC)[응답]
• 나는 우리의 20년 남은 기간 동안 옵션 A로 바꾸는 것이 좋긴 하지만 옵션 D가 장기 로고는 좋은 옵션이 아니라는 것에 동의한다.배치를 할 사람을 찾을 수 있는 한 어느 쪽도 시행하는 것이 어렵지 않을 것이다.그래도 이번 주말까지는 할 수 있을 거야.— Wug·a·po·des 05:12, 2021년 1월 15일 (UTC)[응답]
• 멋진 농담으로 D 하루만...A를 해당 월에 사용한다.--Moxy 🍁 05:25, 2021년 1월 15일 (UTC)[응답]
• 나도 조금 있다가 A로 바꾸는 생각이 좋아.기껏해야 며칠에서 일주일 이상 D를 지킬 필요는 없을 것 같다.남은 달 동안 또는 그 이상 동안 A로 전환하십시오.— 이어비히 05:57, 2021년 1월 15일 (UTC)[응답]
• 20시간이면 충분할 것이다: 이 모든 색깔들과 더 오래 유지할 필요가 거의 없기 때문에, 사람들은 우리가 정말로 이 기회에 많은 관심을 가지고 있다는 것을 이해했을 것이다.로고 파일:WP20 EnWiki20 SimplifiedLogo.svg는 더 긴 기간 동안 괜찮다.네모 06:58, 2021년 1월 15일 (UTC)[응답]
• 옵션 D의 일주일을 넘지 않는다. 얼마나 긴 축하행사가 진행될지는 모르겠지만 그때까지는 끝내야 한다. power~enwiki (π, ν) 07:00, 2021년 1월 15일 (UTC)[응답]
• 20일 정도면 괜찮을 것 같아.—DJ (대화 • 기여) 09:18, 2021년 1월 15일 (UTC)[응답]
• 고통스러울 정도로 밝은 우리 로고가 일주일 이상 안 되면(장타자 잘 치지 말고, 크게 튀기면 괜찮다), 72시간이 더 나을 것이다.단 하루만.위의 몇 가지 로고와 같이, 나는 좀 더 차분한 "A" 로고를 2-4주 정도 쓰면 행복할 것이다.노즈백베어 (토크) 09:50, 2021년 1월 15일 (UTC)[응답]
• 20일 정도면 괜찮을 것 같아.나는 전체 기간동안 D를 보관할것이다.이후 일정 기간 동안 원본 로고 또는 옵션 A로 되돌릴 것인지에 대한 의견 없음.늑장부리는 Reader (대화) 10:25, 2021년 1월 15일 (UTC)[응답]
• 단 하루만 좋은 것 같은데, 꼭 더 오래 유지해야 한다면 남은 시간 동안 (A)로 바꾸는 게 좋을 것 같아.그리고, '자유 백과사전'으로 돌아가도 될까?우리는 10억개의 편집에서 아직 1,000개의 요소를 가지고 있고, 단지 1억개 정도 밖에 되지 않는다.고마워요.마이크 필 (토크) 10:54, 2021년 1월 15일 (UTC)[응답]
• 10억의 정의는 두 가지 이상이다.우리의 기사를 보라.브릿맥스 (대화) 11시 17분, 2021년 1월 15일 (UTC)[응답하라]
  • @Britishmax: 정확해, 그래서 그 단어를 사용하지 않는 것이 가장 좋은 거야.고마워요.마이크 필(토크) 11시 37분, 2021년 1월 15일 (UTC)[응답]
    • 좋은 지적이야.브릿맥스 (대화) 11시 39분, 2021년 1월 15일 (UTC)[응답]
      • 10억으로 백만이라는 것은 영국의 변종이라고 되어 있지만, 내 영국인 자신은 단 한 사람도 IRL을 그렇게 사용하는 것을 들어본 적이 없고, 뉴스나 책 등은 그런 식으로 사용하는 것이 아니다.나라마다 다르겠지만 여기서 사용할 수 있을 만큼 우세한 것 같아.어느 시점에서는 지역적인 선택을 해야 한다.아직 아무도 "100 크로어"를 제안하지 않았는데, 그것은 우리 독자들 중 수백만 (수십 라크)이 가장 자연스럽다고 생각할 것이다.— 빌로프 (대화) 15:16, 2021년 1월 15일 (UTC)[응답]
        • 나는 영국 출신이지만 '억만'을 들을 때마다 실제로 어떤 의미가 있는지 다시 한번 확인해야 한다.크로레/라흐의 좋은 예.번호로만 주거나 표준 태그라인으로 돌아가 문제를 피하는 것이 어떨까?고마워요.마이크 필(토크) 18:05, 2021년 1월 15일 (UTC)[응답]
        • 그렇다면 나는 빌로프, 네가 나보다 어리다고 의심한다.내가 1960년대와 1970년대에 영국에서 학교를 다닐 때 '억'은 영국식 영어로 100만이라는 것을 분명히 의미했지만, 1990년대에 내 아이들이 학교에 다닐 때쯤에는 더 흔한 의미가 1억이 되었다.우리 중 몇몇은 아직 살아있고 온라인 백과사전을 읽고 있기 때문에, 가능하다면 모호함은 피해야 한다.필 브리저 (대화) 18:47, 2021년 1월 18일 (UTC)[응답]
          • 물론 억만이라는 용어에 대한 '올바른' 이해는 실로 백만이다.우리 모두는 이것을 알고 있다.슬프게도, 우리 고향의 우리는 전 성직자들의 사용으로 인해 지나치게 압박을 받고 있어서 10억에 대한 그들의 이해를 십억에 이르는 경향이 있다.우리는 그들이 틀렸다는 것을 알고 있지만, 사용법이 사방으로 퍼지고 있다.그러므로 "억"은 어떤 사람들에게는 혼란스러운 용어가 될 것 같다.하지만 나는 이 경우 대부분의 사람들이 10억이라는 단어를 실제 숫자로 내면화하지 않고 위키피디아가 "많은" 편집을 했다는 것을 받아들일 것이라고 추측한다.정말 그것으로 충분하다.우리는 많은 일을 했고, 그것에 대해 정당하게 행복했고, 그것은 좋은 일이다 - 고스트인The Machine 20:32, 2021년 1월 18일 (UTC)[응답]
• 하루에서 며칠 정도, 정확한 사이트에 있는지 사용자들을 혼란스럽게 하는 경향이 있다고 생각한다.알란스코트워커 (대화) 13:12, 2021년 1월 15일 (UTC)[응답]
• 1주일은 내게 합리적인 것 같다.나의 대략적인 감각은 대부분의 사람들이 적어도 그렇게 자주 위키피디아를 방문한다는 것이다. 그래서 그렇게 오랫동안 위키피디아를 유지하면 모든 사람들이 그것을 볼 수 있는 기회를 얻을 수 있을 것이다.그 이상의 것은 그냥 지칠 뿐이다.{{u Sdkb}} 13:32, 2021년 1월 15일 (UTC)[응답]
• 앞으로 영구적으로 사용해도 나는 개의치 않을 것이다.사이트에 새로운 색상을 추가해 회색과 흰색의 단조로움을 깨뜨린다. --캘리덤 15:35, 2021년 1월 15일 (UTC)[응답]
• 인간적으로 가능한 한 짧게.임호 이건 혐오스러운 일이고, 나도 그만큼 말하려고 이 페이지를 찾아온 거야.'20년'을 기념하고 싶다면 화환 같은 곳에 20이라는 숫자를 넣어라, 내가 이것을 보았을 때, 내 첫 번째 생각은 위키미디아가 마침내 구글에 품절되었다는 것이었다.이 "실리콘 밸리" 예술 스타일은 영혼이 없는 만큼 미적으로 추악하다.어쩌면 위키미디아가 드디어 소매에 이런 스타일을 입게 되는 것만이 어울리겠지만, 적어도 나에게는 축하 분위기를 제시하지는 않는다. --dab (19:18, 2021년 1월 15일 (UTC)[응답]
• 아이콘은 최소 시간 동안 작동해야 한다.여러 명이 그렇게 제안하고 있는 것 같으니까, A옵션은 월 20일 휴식 시간이 적당하다고 생각한다. --Izno (토크) 19:45, 2021년 1월 15일 (UTC)[응답]
• 주말에 D를 업으로 두고 월요일에 A로 전환한다.Mjroot (대화) 20:15, 2021년 1월 15일 (UTC)[응답]
• 옵션 D는 오늘(실행된 시점부터 24시간, 그 시점까지) 하루 종일 깨어 있어야 한다.내 생각에 옵션 A가 훨씬 더 낫고, 나는 그것을 2주 동안 볼 용의가 있다.나는 한 달 내내 바보같이 느껴지고, 1년은 더 그렇게 느껴져.— 고세이 (대화) 21:30, 2021년 1월 15일 (UTC)[응답]
• 가능한 한 빨리 A로 전환하십시오.D는 추하고, 유명하지 않으며, (많은 비미국 진보주의자들에게) 여성 억압의 상징이 되기도 한다.미쳤어. 롤로(토크) 22:10, 2021년 1월 15일 (UTC)[응답하라]
• 사이트 전체 1일 / 1주일 기본 페이지.장기적이라면 A로 전환하십시오.이것은 축하하는 사람들과 일하는 사람들 모두에게 좋은 타협이다.충심으로, 역사 DMZ 00:22, 2021년 1월 16일 (UTC)[응답]
• 이 일이 오래 지속되지 않기를 바란다.그래, 다른 선택지에 투표할 기회를 놓쳤지. 하지만 난 아마 그 어떤 것에도 투표하지 않았을 거야.솔직히 어떤 기기(전화, 데스크탑, 태블릿 등)를 사용하느냐에 따라 네 개의 이미지(사실상 1개) 중 하나를 클릭할 수 있는 기능이라고 처음 생각했다.dab이 지적한 바와 같이, 이러한 cutsy-primary-colors 미학으로는 그다지 잘 되지 않는다.---sluzelin talk 00:31, 2021년 1월 16일 (UTC)[응답]
• 옵션 D는 2일이라고 하고, 그 다음 옵션 A로 바꿔서 20일 동안 그대로 두도록 한다. 판다케콕9 (대화) 03:21, 2021년 1월 16일 (UTC)[응답]
• 두 편집자가 모두 옵션 A로 변경하고 1년 동안 떠나는 것에 동의할 것이라는 의견이 8개 정도 있다(적어도 한 달은 더 시사하는 바가 몇 개 더 있다, 또한 대다수가 옵션 A를 선호한다는 상기 게시물을 읽음으로써 느낌을 얻는다).Ozzie10aaa (대화) 01:29, 2021년 1월 17일 (UTC)[응답]
• 위키피디아는 독자들을 위한 것이다.대부분의 독자들은 그것이 기념일이라는 것에 신경 쓰지 않을 수 없었고, 기념일 로고의 시각적 손길이 산만하다.위키피디아는 기고자들을 위한 것이다.그것의 기고자들은 장난스러운 퍼즐 공으로 사이트에 기고하는데 몇 년을 보냈다.이것을 "가능한 한 빨리"에 대한 또 다른 투표로 간주하라. (옵션 A는 괜찮지만, 많은 독자들은 "10억 편집"이 무엇을 의미하는지조차 알지 못할 것이라고 생각한다.그래, 위키피디아가 만들어지는 과정은 축하할 일이긴 하지만, 결국 사람들은 자신이 찾는 정보가 여기에 있는지, 그것이 맞는지에만 신경을 쓴다.) -- Zanimum (대화) 15:32, 2021년 1월 17일 (UTC)[응답]
• 오늘보다 더 길어질 거면 훨씬 더 폭넓은 논의가 필요하다.나는 현재의 현수막에 대해 10 대 1의 투표를 예상한다.나에게 이것은 완전히 대표되는 토론 없이 사이트 전체에서 변경을 하는 것에 대한 주의사항이다. DGG (토크) 18:42, 2021년 1월 17일 (UTC)[응답]
  • 약 7주 전, 바로 이 페이지에 처음 제안되었다. --Redrose64 🌹 (토크) 21:23, 2021년 1월 17일 (UTC)[응답]
• UTC 1월 19일 0:00부터 옵션 A로 전환하고 해당 달의 나머지 기간 동안 옵션 A를 유지하십시오.Some1 (대화) 23:55, 2021년 1월 17일 (UTC)[응답]
• 내 생각에, 그것을 무너뜨릴 시간이다.~48시간(최소한 하나의 시간대에서 위키백과의 생일이었던 기간)이면 충분히 길었을 것이다. --에어랜드(토크) 00:02, 2021년 1월 18일(UTC)[응답]

내일 00시에 받아 적는 게 좋을 것 같아.그만해.--위활트(대화) 01:41, 2021년 1월 18일 (UTC)[응답]

• 옵션 D는 끔찍하다(단 1표 '대세'로 받아들여진다), 빨리 사라질수록 좋다(어제 너무 늦었다).파블로 (대화) 06:16, 2021년 1월 18일 (UTC)[응답]
• 이미지의 요소들을 놓고 고민하던 중 즉시 제거하십시오.

스트라이크 1: 네 장의 사진은 공식 자료에서 나온 것으로 되어 있지만, 그 중 세 장만 그렇게 하고 있다 – 왼쪽 아래에 있는 휴대전화는 그 세트의 일부가 아니며, 대신에 이것은 모바일 사용을 나타내기 위한 것이다.

스트라이크 2: 왼쪽 위 이미지는 위키피디아가 아닌 위키다양성을 상징하도록 되어 있다.다른 프로젝트에 사용할 아이콘을 사용하는 것은 꽤 잘못된 것 같다.

스트라이크 3: 행사 요점을 상징하기 위해 만들어진 아이콘은 하나도 포함되지 않았다 – 케이크, 불꽃놀이, 심지어 숫자 20도 포함되지 않았다.

Andrew🐉 (대화) 11:36, 2021년 1월 18일 (UTC)[응답]

가능한 한 빨리 A로 전환하십시오.A를 2주 더 방치 — GhostInThe Machine 11:48, 2021년 1월 18일 (UTC)[응답]

• A로 전환하거나 Remove I!voted for D가 하루 동안 실행된다는 가정 하에 D를 위해 예약한 경우, 사이트 방문자가 이를 알아차릴 수 있을 만큼 충분히 불안했기 때문이다.중, 장기에 머물기에는 너무 화려하다는 데 동의한다.요크셔라드 ✿ 12^(talk):02, 2021년 1월 18일 (UTC)[응답]

D는 충분히 오랫동안 켜져 있었다. A로의 전환은 좀 더 빨리, 또는 원래의 것으로 돌아가라.A가 한 달 정도 계속 켜져 있는지 여부에 대해서는 특별히 염려하지 않는다.····피터 사우스우드 : 15:52, 2021년 1월 18일 (UTC)[응답]

• 옵션 A가 일정 기간(월~년) 머문다면 A I am OK로 전환. --Enos733 (대화) 16:14, 2021년 1월 18일 (UTC)[응답]
• 가능한 한 빨리 A로 전환하십시오.현재 로고는 최대 일주일간 스페셜로 멋지지만, 만약 우리가 장기간의 무언가를 하고 싶다면 A나 오리지널로 가라.— JackFromRedsburg (대화 • 기여) 00:52, 2021년 1월 19일 (UTC)[응답]
• 나도 A로 바꿔야 할 만큼 현재의 로고가 오래되었다고 생각한다.케빈L (일명 L235 · t · c) 09:03, 2021년 1월 19일 (UTC)[응답]
• 나는 더 이상 여기서 편집하지 않지만, 이런 기념행사를 하기에 한 달이 충분한 것 같아.나는 옵션 D를 실제로 좋아하는 몇 안 되는 사람들 중 한 명이다. 특별한 날이기 때문이다. 하지만 만약 합의가 그러한 결론에 도달한다면 옵션 A는 괜찮다.— 게스리드 (대화) 14:29, 2021년 1월 19일 (UTC)[응답]
• Keep D until tomorrow (21st) and then switch to A and keep it until 15th April. -- CptViraj (talk) 14:02, 20 January 2021 (UTC)[reply]

Resolved

– Margin increased in site css files. — xaosflux ^Talk 00:59, 15 January 2021 (UTC)[reply]

Guys, right now this looks like this on my main page:

"OVER ONE BILLION EDITS" is cut off, and "Navigation" overlaps. It's like this on other pages also. Please fix. Cheers! BD2412 T 23:44, 14 January 2021 (UTC)[reply]

I see this has already been raised above. BD2412 T 23:47, 14 January 2021 (UTC)[reply]

@BD2412: this should be all patched in now, let us know if it isn't working for you please. — xaosflux^Talk 00:50, 15 January 2021 (UTC)[reply]

It's good enough. The overlap is gone, and the "OVER ONE BILLION EDITS" is all there, although it seems a bit sharp at the bottom. BD2412 T 00:53, 15 January 2021 (UTC)[reply]

Can we fix the color combination in the 4th image....as of now not visible to color blind readers.--Moxy 🍁 00:02, 15 January 2021 (UTC)[reply]

@Moxy: We can try. What color combination would look better for color blind users? You can see the palate at meta:Wikipedia 20/Resources#How to customize the mark but feel free to pick whatever colors you think look best. — Wug·a·po·des 05:47, 15 January 2021 (UTC)[reply]

Accessible Colour Contrast.--Moxy🍁 06:04, 15 January 2021 (UTC)[reply]

@Moxy: this seems stalled, someone will have to want to work on this before the "duration" discussion decides to remove it -- feel free to mock up a new logo if you would like, but it's not a matter of just uploading it to deploy it to code either. — xaosflux ^Talk 00:04, 16 January 2021 (UTC)[reply]

Take this for what it's worth to you, coming from an editor who mostly just does drive-by edits here and there and who's not really part of the "meta-community"... but the new temporary image is so garish it actually motivated me to try and find a place to discuss it. :) I find the colors distract from the article texts, and the overall "aesthetic" sort of reminds me of K-12 sites from 20 years ago. The drawings themselves are competently-executed, it's just really out of place in what has traditionally been a greyscale, unobtrusive area. I appreciate that someone put some time and energy into it and that at least several people seem to have figured it was okay enough to win the above vote, but... man... oof. Anyway, feel free to refactor or move this to wherever people are discussing the image post-implementation, not calling for anyone's head here, just felt like I had to speak out! WonnE66 (talk) 01:23, 15 January 2021 (UTC)[reply]

• I concur with the above. It's really distracting when trying to read articles. 72.209.60.95 (talk) 01:29, 15 January 2021 (UTC)[reply]
• I feel that going off-script is warranted for celebrating 20 years. I'm glad you found your way here to share your opinion though. To 20 more years! Brightgalrs (/braɪtˈɡæl.ərˌɛs/)^[ᴛ] 03:35, 15 January 2021 (UTC)[reply]

A HORSE
(as determined by consensus)

• I am sorry to say that the new image -- which I dearly hope is only temporary -- is truly, truly awful. I'm afraid this is one of those times when consensus really wasn't the best method to arrive at a good result. Beyond My Ken (talk) 03:54, 15 January 2021 (UTC)[reply]

  @Beyond My Ken: yes, temporary #Duration above is discussing how temporary. — xaosflux ^Talk 04:21, 15 January 2021 (UTC)[reply]

  Yes, it looks like clip art from Windows 95. Ceoil (talk) 15:34, 15 January 2021 (UTC)[reply]

• Question: Is it a known issue that when you go to "page information pages" (e.g. for the main page) it still shows the old logo? (Xaosflux or other user with technical knowledge) Sam-2727 (talk) 05:53, 15 January 2021 (UTC)[reply]

  Sam-2727, your cache has likely not updated. You can try purging your browser cache to fix it. Nihlus 06:07, 15 January 2021 (UTC)[reply]

  Nihlus, Thanks that worked Sam-2727 (talk) 14:28, 15 January 2021 (UTC)[reply]

• Comment It should read "more than 1 billion edits" not "over one billion edits". Lugnuts^{Fire Walk with Me} 09:18, 15 January 2021 (UTC)[reply]

  Lugnuts, I agree ("more than" is better grammar, and I think "1" looks cleaner). I thought about bringing it up earlier but decided not to since I didn't want to risk derailing anything. {{u Sdkb}}^talk 12:37, 15 January 2021 (UTC)[reply]

  (Also, is anyone else super reminded of the McDonalds tagline haha?) {{u Sdkb}} ^talk 12:44, 15 January 2021 (UTC)[reply]

• It seems symbolic not of 20 years ago, but 40: it brought back a memory of CGA graphics. DGG ( talk ) 18:12, 17 January 2021 (UTC)[reply]
• I never thought I would be so motivated to go out of my way to complain about a new (albeit temporary) logo, but here I am. I agree with BMK; it really is dreadful.--WaltCip-(talk) 20:40, 17 January 2021 (UTC)[reply]

HTML tag <title> defines the text, which web browsers usually use to label tabs. The <title> tag on English Wikipedia is controlled through the page MediaWiki:Pagetitle (see mw:Manual:Interface/Pagetitle for details). English Wikipedia uses the default $1 - {{SITENAME}}, where $1 is replaced by the full page name, magic word {{SITENAME}} is substituted to "Wikipedia", and they are separated by a spaced hyphen. For example, this page has <title>Wikipedia:Village pump (proposals) - Wikipedia</title>. Different wikis use different separators. Examples (note that wiki-local internationalization preferences affect the page title—use incognito/private tab to see actual tab name):

I propose replacing the hyphen at English Wikipedia's MediaWiki:Pagetitle with an en-dash, which is a more appropriate separator—see MOS:ENDASH. — andrybak (talk) 16:29, 3 November 2020 (UTC)[reply]

• I don't think this is necessary, and keep in mind would only change for users with the English interface language set (everyone else will still get the system default). — xaosflux ^Talk 18:29, 3 November 2020 (UTC)[reply]
• Support per MOS:ENDASH. This seems like a pretty simple grammar fix (albeit with a huge scale), so I'm not sure it needs a giant discussion here, but I'm also not sure where else the discussion would've been hosted, so I can see why you brought it here. To speak to Xaosflux's point, this shouldn't be something that only applies to English, so if we can figure out how to apply it to all languages, that'd be even better. {{u Sdkb}}^talk 22:56, 3 November 2020 (UTC)[reply]

  Shouldn't the punctuation on each project conform to its own language and MOS? The MOS on enwiki would certainly indicate that an en dash, not a hyphen, should be used here, but an em dash or hyphen may be correct in other languages. A centralized discussion on Meta would be a good place to confirm that each project's tab punctuation adheres to its own MOS. Armadillopteryx 00:46, 4 November 2020 (UTC)[reply]

• Meh for en.wiki; they're all just horizontal lines. 99% of users have never noticed, and of that 1%, 96% won't care. None of our business for all other wikis. I assume I'm misunderstanding Sdkb's comment; you aren't suggesting that the result of a discussion here should affect all other wikis? --Floquenbeam (talk) 23:29, 3 November 2020 (UTC)[reply]

  @Floquenbeam: From what Xaosflux said above, it seems that a fix might only apply to the English Wikipedia with the English language interface set, not all language interfaces. We control all language interfaces on English Wikipedia. As for other Wikipedias, it might be nice to standardize among those, but that discussion would probably have to be held somewhere on Meta. {{u Sdkb}}^talk 23:35, 3 November 2020 (UTC)[reply]

  It's very likely you know more than me about this. But "We control all language interfaces on English Wikipedia" doesn't sound right at all. I think I must be missing a subtlety or distinction or term of art? Anyway, it isn't important that I understand. As long as you're not saying we should make changes for, say, es.wiki or Commons too - which it looks like you're not saying - then we're good. --Floquenbeam (talk) 23:42, 3 November 2020 (UTC)[reply]

  In Special:Preferences you can set your language. If unset or set to a language that doesn't have a locally created MediaWiki page, there is a default MediaWiki page used. Killiondude (talk) 00:19, 4 November 2020 (UTC)[reply]

  MediaWiki has a framework to support translations into different languages in its own user interface messages, as described by Killiondude, which is what Sdkb is describing regarding having control over all language interfaces on English Wikipedia. It has been long recommended for users not to change their preferences to another language, though, as a lot (most? all?) of customized messages have not been translated (and as I recall, even specifying a country-specific English variant, like en-uk, will cause a fallback to the default message, thereby losing the customization). isaacl (talk) 00:36, 4 November 2020 (UTC)[reply]

  @Killiondude and Isaacl: actually it seems that if a custom message is set but not translated, the custom message is used. At least in the sidebar - go to https://en.wikipedia.org/wiki/Earth?uselang=de (an en.wp page but with the interface language set to German). The second item in the "contribute"/"Mitmachen" section is the custom English "Learn to edit" in both English and German interfaces rather than the default "Introduction" / "Einführung". Thryduulf (talk) 01:41, 4 November 2020 (UTC)[reply]

  You can see what impact changing the interface language would have by appending ?uselang=xx (where xx is the language code you want to use) to the URL (or &uselang=xx if the URL already contains a ?). For example go to https://en.wikipedia.org/wiki/Earth?uselang=de to see an English Wikipedia article with the interface language in German. The article text remains in English, but all the tabs, sidebar links, etc. are in German. Thryduulf (talk) 01:41, 4 November 2020 (UTC)[reply]

  It took you all more effort than it was probably worth, but I finally understand. Thanks everyone for the patient explanations, sorry everyone for being technologically incompetent, and sorry User:Sdkb for momentarily implying you might have been saying something crazy. --Floquenbeam (talk) 16:26, 4 November 2020 (UTC)[reply]

  No worries at all! {{u Sdkb}} ^talk 19:31, 4 November 2020 (UTC)[reply]

• Support this change on enwiki (and other English-language projects) per MOS:ENDASH; projects in other languages should make sure the dash (or hyphen) used conforms to their own MOS. Armadillopteryx 00:46, 4 November 2020 (UTC)[reply]
• Comment: previous relevant discussion: Wikipedia:Village pump (proposals)/Archive 135 § Proposal: Amend page title element to remove "Wikipedia, the free encyclopedia". — andrybak (talk) 01:08, 4 November 2020 (UTC)[reply]

Support, hyphens are not used for this purpose, WP:NDASH. Nixinova T C 02:23, 4 November 2020 (UTC)[reply]

• Support. It's a tiny, tiny thing...but honestly, I would be happy to see it happen.—Neil Shah-Quinn (talk) 15:11, 6 November 2020 (UTC)[reply]
• Support on enwiki per Armadillopteryx. 〈 Forbes₇₂ Talk 〉 16:28, 6 November 2020 (UTC)[reply]
• Comment: should an RFC be opened to gather more feedback? — andrybak (talk) 16:01, 8 November 2020 (UTC)[reply]
• Support – It shouldn't be a question that our interface should generally conform to the MOS absent any reason to the contrary. 207.161.86.162 (talk) 03:26, 9 November 2020 (UTC)[reply]
• Tentative support, but I am wonder whether there is a technical reason that hyphens in page titles are so common, even for sites with strict style manuals. For example, both the New York Times and the BBC have hyphens in their page titles. Indeed, it looks like every site in my browser bookmarks that has equivalent punctuation has a hyphen (except that my university's Blackboard Learn site has both a hyphen and an en dash in the title, which looks quite ugly now that I have noticed it). Any thoughts about why that might be? blameless 21:01, 9 November 2020 (UTC)[reply]
  • Withdrawing my support per the below and continued investigation. It was said above that "hyphens are not used for this purpose"--I am certainly a descriptivist, and I would say that hyphens are used for this purpose for purely internet-based instances of language (such as browser tabs) that are entirely separate from prose content, for the sake of consistency and reliability across browsers and character sets. Neutral. blameless 19:26, 26 November 2020 (UTC)[reply]
• Oppose or replace with pipe. Browser tabs have limited horizontal space, and the only effect of this proposal is to waste a bit more of it. Perhaps this is why it is so common to use a hyphen or a pipe rather than an en-dash or em-dash. ST47 (talk) 21:29, 9 November 2020 (UTC)[reply]

  ST47, I'd have thought that the pipe would take up less space than an endash. I've tested in Firefox and Chromium in Ubuntu. In Firefox the pipe takes up more space than endash (font Noto Sans 10pt). In Chromium both take up the same amount of space (I couldn't figure out which font is used). — andrybak (talk) 23:06, 9 November 2020 (UTC)[reply]

• My browser (Firefox on Debian) follows our page title (and every other page title) with " - Mozilla Firefox" so using a dash or pipe would make my browser title look weird. Is that enough to oppose? I don't know, but clearly hyphens are pretty standard separators in how browsers display page titles. Additionally, it's probably better that our page titles are ASCII-compliant, and this change would move us away from that. This could affect page downloads or distribution on offline hardware. My main concern is that we gain pretty much no benefit, but there might be hidden problems it introduces. — Wug·a·po·des 23:55, 9 November 2020 (UTC)[reply]
• Meh Not worth the trouble for all the reasons Wugapodes mentioned. Probably nothing will break, but the benefit is so small it's not worth doing. The hyphen-minus is also the standard window title element separator on every non-Apple platform. An en/em dash will take up more space, which is undesirable. Switching to pipes would change the visual style, and I'm not a fan of that idea either (the hyphen-minus is the most common <title> separator anyway. --AntiCompositeNumber (talk) 00:27, 10 November 2020 (UTC)[reply]
• Oppose Browser has limited space. Also, the proposal text doesn't clearly say which Hyphen#In_computing is currently used. Hyphen-minus is ASCII. If it currently is ASCII, then stay with ASCII for less interference with third party systems. TerraCyprus (talk) 23:26, 10 November 2020 (UTC)[reply]

  Sticking to ASCII is about 3 decades out of date, and is in general too limiting, even for English. Dicklyon (talk) 21:56, 10 December 2020 (UTC)[reply]

  TerraCyprus, regarding If it currently is ASCII, then stay with ASCII for less interference with third party systems. tag <title> already contains dashes and much more of the Unicode. E.g. Ágústa Þorsteinsdóttir, 燒酒. — andrybak (talk) 16:59, 31 December 2020 (UTC)[reply]

• Meh (Is Meh a valid voting option?) The title is also used for bookmarks, and so the site suffix has some value there, but I generally edit the titles to make sense to me and normally remove the suffix. Most of the time the tab is too narrow to display all of the article title, so the "- Wikipedia" site suffix is lost anyway. Personally, I would delete the site suffix from the titles as the icon at the start is enough to identify the tab, but I do suspect that would be seen as a step too far — GhostInTheMachine ^{talk to me} 11:59, 14 November 2020 (UTC)[reply]
• Meh because I'm not sure I'll ever encounter a Wikipedia debate that warrants "meh" as much as this one. I'm sympathetic to both sides, but would probably favor the character that can be entered with one tap of the keystroke and is easily identified by non-native English speakers who don't even know what an en- or em-dash is. On the other hand no one's really going to be typing this on their own. Also, what were French and Russian Wikipedias thinking when they instituted the em-dash? -- FuzheadoTalk 20:46, 16 November 2020 (UTC)[reply]

  Fuzheado, Russian Wikipedia's MOS is based mostly on current Russian grammar and typography practices. Same is probably true for the French Wikipedia. — andrybak (talk) 07:49, 23 January 2021 (UTC)[reply]

• Comment: I have requested closure of this discussion at WP:ANRFC. — andrybak (talk) 18:25, 23 November 2020 (UTC)[reply]
• Support. The use of the hyphen here is an old "lazyism" from pre-MOS:DASH days. Should have been corrected a long time ago. — SMcCandlish ☏ ¢ 😼 03:49, 8 December 2020 (UTC)[reply]
• Support –definitely. It's professional English, and apart from being in accordance with the major style guides (including ours), it's slightly easier to read. I don't care if other languages want to stick with their shabby little hyphens. Tony (talk) 09:34, 8 December 2020 (UTC)[reply]
• Yes, Support the hyphen is a lazy substitute for the intended punctuation, a dash of some sort. The spaced en dash is a good choice. Those who won't notice the difference won't be bothered. Dicklyon (talk) 06:58, 9 December 2020 (UTC)[reply]
• Support. It's a very minor thing, but we may as well follow proper professional usage. Alkari (?), 10 December 2020, 04:29 UTC
• Oppose Pretty much what Floq said. I don't have a real "side" as far as the actual issue, because, like most people, to me the distinction is essentially meaningless.(Please, please don't feel compelled to explain to me how very important it is) So, the only concern here is "will this break anything?" And it seems that a few people here are concerned that it might. So, very, very little benefit (arguably none at all) and some risk, so that's a no for me. Beeblebrox (talk) 00:04, 19 December 2020 (UTC)[reply]
• Support. I found myself on both sides while writing this comment, but settled in support. The MOS is clear that an en-dash is preferred over a hyphen as a separator here. The most cogent objection is that the en-dash may cause certain technical issues, and there's a lesser point that it takes up more space. However, this same reasoning would apply to our many articles that are titled with – or — instead of -, or indeed any other non-ASCII characters, which all show up in the <title> tag. And yet, MOS:DASH has been in place for article titles for many, many years with no apparent problems. The fact that dewiki, frwiki, and ruwiki all use some form of dash also supports this point. We can always revert the change if we find out about some unexpected side effect. — The Earwig ^talk 06:11, 27 December 2020 (UTC)[reply]
• Oppose If it works, don't fix it. Andrew🐉(talk) 13:00, 28 December 2020 (UTC)[reply]
• Oppose Why so many people have this thing for a character that's not standard and cannot be typed is beyond me. It's constantly forced down our throats for no reason. - The Bushranger_{One ping only} 07:20, 31 December 2020 (UTC)[reply]

  The Bushranger, regarding a character that's [...] cannot be typed. On Windows, it can be typed using the ⊞ Win+. menu (under Ω tab), on macOS it is ⌥ Option+-, on most Linux distributions it is Alt+-+-+. (via XCompose feature), on Android and iOS most keyboard apps support it on long press of the hyphen -. On Wikipedia, the en-dash can be inserted using both the editor toolbar (Special Characters > Symbols) and CharInsert extension (first character in the "Insert" group)—both UIs are enabled by default. Also, there is HTML entity –. — andrybak (talk) 16:44, 31 December 2020 (UTC)[reply]

  And it doesn't matter anyway in this context. Bushranger's "utility" argument is inapplicable to something that is simply part of the interface display. — SMcCandlish ☏ ¢ 😼 22:50, 1 January 2021 (UTC)[reply]

• Support per MOS:ENDASH resp. Sdkb and particularly 207.161.86.162 and SMcCandlish, who both expressed my view very succinctly. Similar to The Earwig, I was wavering for some of the same reasons, but above all because of GhostInTheMachine's statement. However, my support was strenghened when I saw that a significant portion of the Oppose votes were because of a fear that something could break, which is absurd IMO given andrybak's point that the title already often contains non-ascii characters. ◅ Sebastian 20:38, 1 January 2021 (UTC)[reply]
• Support. It's small change but conforms better to English style guides. I don't see how typing it is such a problem. This is not a change that implies the need of manually entering the character, and MOS:ENDASH already mandates it for a lot of content. --MarioGom (talk) 14:25, 4 January 2021 (UTC)[reply]
• Support, per the MOS & correct punctuation. Cavalryman (talk) 04:23, 6 January 2021 (UTC).[reply]
• Support it's hard to take a side here, and indeed I don't take either with much confidence. But as a small change that better conforms with MOS and standard English, I think we may as well. Aza24 (talk) 01:39, 8 January 2021 (UTC)[reply]
• Don't think MOS applies to page titles. Most sites - massive, big, and small - use a hyphen in page titles. English Wikipedia would be sticking out like a sore thumb. Keep the hyphen. ProcrastinatingReader (talk) 16:40, 13 January 2021 (UTC)[reply]
• Support. MOS:ENDASH. Personally, I was quite getting used to this. MarioJump83! 04:32, 15 January 2021 (UTC)[reply]

Should we have survey convenience templates? Mike Peel (talk) 22:07, 1 January 2021 (UTC)[reply]

While WP:NOTVOTE is really important, we have a lot of discussions/debates (like this one) that people Support/Oppose and comment on. A lot of the Wikimedia projects use templates like {{Support}}, {{Oppose}} etc. to help with this, often also including a symbol. These templates were deleted here back in 2005, mostly because people objected to the inclusion of the symbol.

In this RfC I propose restoring these templates but without the symbol. This would mean that editors could use {{Support}} rather than '''Support''', but it would look the same. It would not be compulsory to use one or the other, and of course the !vote should be accompanied by a rationale regardless. The templates would simply be a convenience for editors that are used to using the other syntax, and would avoid a lot of follow-up edits to fix formatting after trying to use the templates instead of the bold formatting (which I at least frequently do, either after saving or in preview!). Their use would have negligible impact on server load (another concern from 2005), but could easily be bot-substituted (by batches every day/week/month) if that really is still a concern.

(These templates have been frequently recreated since their deletion, to the extent that it is a perennial request (the difference with this !vote is that it's to meet cross-wiki expectations, and I'm not proposing to use icons). I originally took this to WP:DRV last month as per the latest deletion/protection edit summaries, but an RfC was recommended instead.)

Thanks. Mike Peel (talk) 22:07, 1 January 2021 (UTC)[reply]

Survey (survey convenience templates)

• {{Support}} as proposer. Thanks. Mike Peel (talk) 22:07, 1 January 2021 (UTC)[reply]
• Oppose As I would typically say in TfD, insufficient complexity of markup to warrant a template. I completely fail to see the point of creating a template whose content is its name with three apostrophes prepended and appended, when that is only two characters longer than typing the wikitext out in the first place. * Pppery * _{it has begun...} 22:27, 1 January 2021 (UTC)[reply]

• @Pppery: It's not about the number of characters, it's about the time it takes to remember the syntax, and that the syntax shouldn't depend on which Wikimedia project you are using. The human cost is much more than the syntax cost. It's the same as {{tq}} vs. this alternative way of writing it. Thanks. Mike Peel (talk) 22:38, 1 January 2021 (UTC)[reply]

• I would prefer to type “ {{Support}}” rather than “'''Support'''” because the “'” character is not on the iPad keyboard. {{Support}} could be made to auto-subst. Oppose cut or gaudy pictures. —SmokeyJoe (talk) 23:05, 1 January 2021 (UTC)[reply]
  • my iPad allows me to type a '. Switch the keyboard to punctuation, then press and hold the ‘ key. The pop up menu offers you 4 differs types of quote symbol — GhostInTheMachine^{talk to me} 23:36, 1 January 2021 (UTC)[reply]
    • That was a nice trick to learn! Thank you. Unfortunately, it is very tedious to do the six times. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)[reply]
  • or just type Oppose, select the word and click the B on the editing toolbar — GhostInTheMachine^{talk to me} 23:48, 1 January 2021 (UTC)[reply]
    • Yeah that works. Unfortunately, the toolbar is above the fold. I wish it could be moved to below the editing window. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)[reply]
      • Or you could just try convincing people using words instead of syntax. —Cryptic 06:39, 2 January 2021 (UTC)[reply]
        • I like the simple bold of the lede word of the !vote. Do you dislike that low level of syntax? This !vote bolding culture underlies the working of https://afdstats.toolforge.org/, which is sometimes a nice tool. --SmokeyJoe (talk) 07:00, 2 January 2021 (UTC)[reply]
  • One possible work around is to use iOS's text replacement feature (Settings -> General -> Keyboard -> Text replacement). You can choose any sequence of characters to be replaced by another. For example, you could choose bqq to turn into ''' (three single quotes.) isaacl (talk) 20:23, 9 January 2021 (UTC)[reply]
• Oppose Sorry but no. I understand that moving between projects is a mental pain (I struggle with the equivalent of {{tl xxx}} at Commons) but hiding simple syntax does not help the project. Some projects appear more focused on a vote count, and that idea should not be encouraged here. Johnuniq (talk) 23:08, 1 January 2021 (UTC)[reply]
• Oppose per Johnuniq's comments, especially about hiding syntax. We should not be encouraging anything that gives the impression that votes are more important than the rationale accompanying them. Thryduulf (talk) 23:14, 1 January 2021 (UTC)[reply]

  @Thryduulf: How exactly does the existance of a convenience template give that impression, please? Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)[reply]

  @Mike Peel: the existence of a template, regardless of the formatting it outputs, elevates the importance of that output - if it wasn't important then why would anybody make a template for it? Why would any template be kept if it wasn't adding something of value? Experienced editors will unlikely gain this impression, but that is not necessarily true of those who are new to Wikipedia or who have a limited understanding of how XfD discussions work (if there wasn't an impression they are votes then we wouldn't need boilerplates like {{not a vote}}). Thryduulf (talk) 23:57, 3 January 2021 (UTC)[reply]

  I disagree with that thinking, I don't think having the template would give any more weight to a new user's thinking that they can !vote than seeing a list of bold-formatted support/oppose votes that they could copy/paste would. Thanks. Mike Peel (talk) 09:30, 4 January 2021 (UTC)[reply]

• Oppose what would the Support template expand to, other than Support in bold? — GhostInTheMachine^{talk to me} 23:45, 1 January 2021 (UTC)[reply]
  • I would have the string {{Support}} auto-change and substitute to '''Support'''. I would find it useful, for the same end result. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)[reply]
• weak support I don't think it unreasonable request--no reason to make anyone's editing harder and it sounds like there are a few people it would help. That said, the help is minor and the worries about a slippery slope to voting aren't utterly trivial. So a small thing that helps people now vs. a very unlikely thing (but not impossible) that might hurt the culture down the road? I'm gently leaning toward the short-term gains being worth the improbable long-term risk. Hobit (talk) 04:32, 2 January 2021 (UTC)[reply]
• Oppose per Johnuniq ~ HAL333 04:45, 2 January 2021 (UTC)[reply]
• weak Support If we can have {{Agree}} and {{Disagree}} why not Support or Oppose? RudolfRed (talk) 05:03, 2 January 2021 (UTC)[reply]
  • Like this: {{agree 1=Support}} → Support . Now, how to lose the gaudy green tick? --SmokeyJoe (talk) 06:55, 2 January 2021 (UTC)[reply]
  • {{strong}}? {{strong Support}} → Support. --SmokeyJoe (talk) 07:06, 2 January 2021 (UTC)[reply]
    • Does it substitute? {{subst:strong Support}} → Support. --SmokeyJoe (talk) 07:46, 2 January 2021 (UTC)[reply]
      • <strong {{#if: role="{{{role}}}"}} {{#if: class="{{{class}}}"}} {{#if: id="{{{id}}}"}} {{#if: style="{{{style}}}"}} {{#if: title="{{{title}}}"}}>Support</strong>. Oh dear, that's a mess of wikimarkup, isn't it. --SmokeyJoe (talk) 07:48, 2 January 2021 (UTC)[reply]
• Usually I eschew starting my comment with a bolded word, precisely to place emphasis on discussion over voting. Assuming the community is truly dedicated to making decisions through discussion, I do not favour having templates that give more prominence to votes. isaacl (talk) 07:18, 2 January 2021 (UTC)[reply]

  @Isaacl: the opposite is that there are so many words in a section that prefacing the section with a bold helps you know what to expect, especially in confusingly worded arguments you know better what they're trying to get at. eg when closing RfCs I don't necessarily close based on vote, but knowing a binary yes/no before a comment helps follow the comment and get a general feel of where the discussion lies. ProcrastinatingReader (talk) 19:20, 2 January 2021 (UTC)[reply]

  I wrote something similar once about how knowing where an argument is heading can help provide context and thus improve understanding. Nonetheless, it can be done with a thesis sentence, rather than a single bolded word. I appreciate many people like starting with a single bolded word. I believe, though, that it puts more emphasis on voting and tabulation of votes versus discussion. isaacl (talk) 19:28, 2 January 2021 (UTC)[reply]

  User:Isaacl, you are assuming that others find it as easy to read or write a thesis sentence as you do. E.g. people with dyslexia, ESL, inexperience with writing topic sentences) I personally struggle to summarise positions into a sentence for many reasons. It was also helpful to me as a new editor that there's a format which people are generally using to help me feel able to engage with discussions. --Xurizuri (talk) 11:33, 12 January 2021 (UTC)[reply]

  If someone can't, that's OK. Starting with "I support the proposal," is fine. If we're trying to encourage discussion amongst those who have opted to contribute to a writing project, though, I think it's reasonable to aspire for participants to craft a concise explanation of their viewpoint. Though it'll likely remain an ideal, it's a good target to aim for. isaacl (talk) 17:00, 12 January 2021 (UTC)[reply]

  The practice became widespread because editors felt it worked best. It has persisted because editors continue to feel it works best (for the most part, although many surely do it because they see others doing it). To my mind, there is no higher principle than that, and there is something to be said for consistency in formatting (some handle the variation better than others, and I'm in the latter group). But whether to use a bolded first word and whether to create templates for it are separate and independent questions. ―Mandruss☎ 18:42, 12 January 2021 (UTC)[reply]

  Yes, as I said, I appreciate many people like to start their response with a bolded word. isaacl (talk) 01:01, 13 January 2021 (UTC)[reply]

• I'll support such templates, not because I'd use them myself, but I see no justification for preventing other people from using them. When instructions are given for how to participate in XFD discussions, a summary word in bold is suggested.[3][4][5][6][7] On the rare occasions when I take part in such discussions on other wikis I have to go round searching other people's comments for the appropriate syntax so I can sympathise with the difficulties of occasional !voters here. Thincat (talk) 09:48, 2 January 2021 (UTC)[reply]
• Oppose. This is a good example of the failure to understand the cost of complexity in terms of barrier to entry. Multiple ways to accomplish the same thing is unnecessary complexity, unjustified by the perceived need to let every editor "have it their way" (apparently because they are unpaid). Anyway, the template syntax is no less prone to typing error than the markup. In the worst case the editor can omit the bolding and it may be fixed by another editor per TPO. To the extent that is not done, a few very rare cases of unbolded !votes are not a significant problem. ―Mandruss ☎ 11:29, 2 January 2021 (UTC)[reply]
• OPPOSE - The goal is simply to highlight what your opinion is. There are lots of ways to do this. As demonstrated here, ALL-CAPS works too. Blueboar (talk) 14:16, 2 January 2021 (UTC)[reply]
• To disincentivise plain voting, we could adopt these templates, but ensure they only output an empty string :) – Uanfala (talk) 16:56, 2 January 2021 (UTC)[reply]
• Oppose This is NOT a problem. No SOLUTION is necessary. GenQuest ^"scribble" 22:02, 2 January 2021 (UTC)[reply]
• Oppose - per User:GenQuest and User:Mandruss (and probably a few others that I agree with for other points). Or, if you wish for greater detail, why would we decrease inconsistency between multiple projects by increasing inconsistency in one project? Having the same method for producing bold "oppose" and "support" as is used for making other things bold throughout Wikipedia is beneficial to the general run of users on Wikipedia.--Khajidha (talk) 00:33, 3 January 2021 (UTC)[reply]
• Support. Minimal implementation cost, minimal burden on other users, and well-defined use case. Thincat put it well. I understand the instinctual "no voting templates!" response, but there's no icon and no emphasis on the opinion. It would be a good idea to brainstorm ways to enforce current community norms around !voting if these templates are created, though. Enterprisey (talk!) 00:52, 3 January 2021 (UTC)[reply]
• Sure. If there are no icons, {{Support}} and {{Oppose}} become shortcuts for wiki markup. As with SmokeyJoe I use an iPad to edit Wikipedia, and typing {{Support}} would be slightly better for me than '''Support'''. I also agree on what Thincat and Enterprisey said. GMX (on the go) 16:00, 3 January 2021 (UTC)[reply]
• {{Support}} The cognitive dissonance of people typing '''Oppose''' in this discussion is remarkable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:19, 3 January 2021 (UTC)[reply]
  • As one of the several people who have explained why a template producing the same output as '''Oppose''' is not desirable I find this ad hominem to be in rather bad taste. Thryduulf (talk) 20:40, 3 January 2021 (UTC)[reply]
    • @Thryduulf: Andy has a point here about how people comment regardless of the existence of the template, it's not an ad hominem. Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)[reply]
      • Effectively calling everyone idiots, without explaining why they're being called idiots, sort of looks like an ad hominem, doesn't it? – Uanfala (talk) 21:45, 3 January 2021 (UTC)[reply]
      • @Mike Peel: if Andy has a point other than insulting the intelligence of people with a different opinion on these templates to him then I am at a loss as to what it is. I can't prove it, obviously, but the impression I get is that he has read only the bolded words (which would be rather ironic for this discussion). Thryduulf (talk) 23:57, 3 January 2021 (UTC)[reply]
      • Competent editors can see that Andy's comment was 100% insult and 0% argument, and therefore a "not-not-vote" of no consequence. A competent closer, if there is a closer, would simply discard it. ―Mandruss ☎ 16:10, 4 January 2021 (UTC)[reply]
• weak support I would not use it, but why not have such a template if it makes it easier for some? Graeme Bartlett (talk) 02:52, 4 January 2021 (UTC)[reply]
• Oppose. Tends to encourage voting rather than discussion aimed at generating a consensus. Solution looking for a problem. Stifle (talk) 09:56, 4 January 2021 (UTC)[reply]
• OPPOSE per Thryduulf, isaacl and Stifle. Those who can't write bold should use the workarounds mentioned above, address their shortcomings (which would help in a far wider range of applicability) or simply write all caps, as Blueboar suggested. ◅ Sebastian 11:17, 4 January 2021 (UTC)[reply]
• Oppose per Johnuniq, Mandruss and GenQuest - This really is a solution looking for a problem. I appreciate Commons etc use {{Support}} however we're not Commons, Every project has their own way of doings things and "'''Support'''" is our way of doing things. Personally I use "'''Support'''" on all projects as it's what I'm used too (unless it looks out of place which I then change it after (ie with RFAs etc)). –Davey2010^Talk 11:30, 4 January 2021 (UTC)[reply]
• Support: trivial implementation, no disruption of previous practices, no migration cost, aligns well with other Wikimedia projects, probably slightly less chance of unbalanced markers (e.g. 2x2 vs 3x3). --MarioGom (talk) 14:06, 4 January 2021 (UTC)[reply]
• As much as I myself mostly start comments with a bold oppose text, I don't think this a template necessary. Firstly, per there being a wide range of commonly used !vote strings and having a template for each is a massive overkill. Will we be needing {{Option 2}} for Option 2 or something? This proposal fails to list (even as example) the actual templates, there are surely more than the two mentioned. And having only a few of these will just create extra differences in markup. I would want to see some statistics of the commonly bolded terms in discussion first. Furthermore, the non-existent complexity of the output does not warrant a template, it is unnecessarily convoluting what is a simple text message, nor is having (even more) templates in text helpful when it's literally default bold syntax. Then there's grammar -- what if I want it lowercase or add other words that need bolding? These just feel like ballot checkboxes rather than a summary of the opinion to follow. Finally, pretty sure this will just make using visual editor way more complicated needing to insert a template when one could have clicked/tapped bold like is standard in every other text editor. — HELLKNOWZ ▎TALK 14:39, 4 January 2021 (UTC)[reply]

  This is a good point - the common recommendations at current discussions are: "allow recreation", "containerize"/"containerise", "convert to an article"/"write an article", "delete", "disambiguate", "draftify", "dual merge", "endorse", "keep", "listfy", "merge", "move", "oppose", "overturn", "purge", "redirect", "refine", "relist", "rename", "rename", "restore", "retarget", "reverse merge", "revert", "setindexify", "soft redirect", "split", "subst", "support", "upmerge", "userfy", "wrap"/"wrapperify" and "wrong venue". Then you have modifiers like "all", "don't", "for now", "in principle", "leaning", "speedy", "strong", "weak" and "without prejudice" and non-recommendation bolds like "comment", "note", "question" and "update". Covering all these would need between 40 and 50 templates. Thryduulf (talk) 13:09, 5 January 2021 (UTC)[reply]

  @Thryduulf: We're only talking about the most common uses of such templates, which are also used on other wikis, like those mentioned in the proposal. There's a latin phrase you could use to explain your comment if you want, though. Thanks. Mike Peel (talk) 22:04, 5 January 2021 (UTC)[reply]

  These are the the recommendations used multiple times in a current discussion and/or in multiple current discussions on en.wp (AfD, RfD, CfD, TfD, MfD, DRV, MRV and RM; although there were none exclusive to MfD). To be useful to editors at en.wp they will need to cover the !votes they will commonly make otherwise they will frequently have to use the standard ''' markup which negates the whole point of having templates in the first place. What other wikis do is not relevant to discussions on the English Wikipedia. Thryduulf (talk) 00:43, 6 January 2021 (UTC)[reply]

• Why not I would never use them, but that doesn't mean that others wouldn't find them useful. Most of the oppose votes are people who have no personal use for them. Why is this even a vote? The OP could have saved themselves some trouble by just creating them. I am struggling to figure out why we needed to even have this discussion/vote. --Jayron32 15:43, 4 January 2021 (UTC)[reply]

  No trouble would have been saved by doing that, because (a) the templates are salted and (b) I would have tagged than as {{db-g4}} if I had noticed them being recreated. We would have ended up here anyway after a few more rounds of bureaucracy. * Pppery * _{it has begun...} 15:47, 4 January 2021 (UTC)[reply]

  It's quite apparent that this is controversial. Sure, people often slip in new templates that would be controversial if discussed beforehand, but I don't consider that good faith practice. Editors are less likely to challenge by WP:TFD because it's such a hassle (and, for some, because they aren't aware of TfD or don't have the time to learn how to use it correctly). If the creation of a template were as easily challenged as an ordinary edit, standard BRD process would work fine, but that is unfortunately not the case. I commend the proposer for "discussing first" in this case, despite the fact that it likely would have been easier to get forgiveness than permission. ―Mandruss ☎ 16:38, 4 January 2021 (UTC)[reply]

My primary concern is that templates (in general) too often shift from being “optional” to being “preferred” ... and then to “expected” and finally to essentially “mandatory”. I know this is not the intent here, but I have seen this shift occur too many times with other templates to be comfortable with it now. Blueboar (talk) 17:03, 4 January 2021 (UTC)[reply]

@Blueboar: Definitely not the intent here. I can't say that this won't happen, but if it does, then presumably it would be accompanied by discussions that you and others (including myself) could object to. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)[reply]

My experience with “template creep” is that there often isn’t any discussion in which to state an objection. So I am objecting NOW, while I have a chance to do so. Blueboar (talk) 22:25, 5 January 2021 (UTC)[reply]

• Orz... can we have "Strong Meh" as well? But really we already have Template:Done/See_also and we also don't have a problem with people actually typing "Support" so I really don't care if a template does it as well, however I don't want to see a proliferation of media like File:Symbol confirmed.svg on every discussion, less concerned if it is stylized text (even check marks that are not image files). — xaosflux^Talk 17:22, 4 January 2021 (UTC)[reply]
  • Sadly {{meh}} already exists as . We would probably want {{weak meh}} as well — GhostInTheMachine ^{talk to me} 10:17, 6 January 2021 (UTC)[reply]
• Even without images, we can still run into problems with a page's transclusion limit which could end up breaking the village pumps or ANI where there are lots of proposals with lots of bolded !votes. Not worth the trouble just to save two keystrokes. I'm also worried about what Blueboar points out with templates going from "optional"->"preferred"->"required" over time. In this case, it would threaten to undermine the already weak "discussion-not-vote" consensus process which worries me per WP:NOTAVOTE and meatball:VotingIsEvil. — Wug·a·po·des 22:20, 4 January 2021 (UTC)[reply]

  We could always have a bot auto-subst them (although it would clutter the page history). Enterprisey (talk!) 08:54, 5 January 2021 (UTC)[reply]

  @Enterprisey: I suggested that in the proposal. I could code up a bot to do so if needed. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)[reply]

  I left it vague, but to be clear, I think that's a worse idea for precisely the reason Enterprisey hints at. The last thing I want is a WP:COSMETICBOT roaming around making non-visible changes to markup and cluttering discussion diffs just to help powerusers save 2 keystrokes. It would probably also make people think they themselves ought to be substituting it which actually costs them 4 keystrokes compared to just using bare markup. — Wug·a·po·des 02:23, 6 January 2021 (UTC)[reply]

• Support without the icon and with substitution to avoid transclusion limit. As other projects have implemented it, I have found myself trying the template before realize that here doesn't work. Alexcalamaro (talk) 23:59, 4 January 2021 (UTC)[reply]
• O - or a bold S is simple enough or better yet, separate the sections like we do at RfA. Atsme💬📧 15:30, 5 January 2021 (UTC)[reply]
  • @Atsme: Great, let's support more options for commenting, like this proposed template? Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)[reply]
• Oppose: or alternatively doing it properly, Hell no. I despise bolded words as a substitute to discussion and the lack of nuance of just going support or oppose is not to be encouraged. Spartaz^Humbug! 19:58, 5 January 2021 (UTC)[reply]
  • @Spartaz: But you just used bold words in your comment? This proposal is for a convenience template to make it easier for other editors to comment, not a substitute. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)[reply]
• Oppose. The convenience factor does not outweigh the barrier to newcomer participation created by use of excessive templates in simple discussions. --SmokeyJoe (talk) 00:19, 7 January 2021 (UTC)[reply]
• Support I support anyone making and using almost any template, and the creation of templates rarely requires a vote or discussion. I must be misunderstanding something here. As noted above, we already have {{agree}} and {{meh}} which are similar templates that people can use or ignore. Why the opposition? No one is proposing to force or require the use of this template, so most people would either not know it exists or not care. Other Wikimedia projects like Commons use these templates, so it is understandable to me that if some people want to use it, then they might look for it across projects. In 2005 the template was deleted for use of images, but no one is proposing that right now. To a typical reader they would not know a template is being used at all.

I think the point of this discussion is that this template has been deleted ~10 times since 2005 because of prior use of images, but I see no harm or cost in having the template available for those who want to use it now. Blue Rasberry (talk) 16:25, 7 January 2021 (UTC)[reply]

• {{weak strongest possible oppose}} Majavah (talk!) 18:51, 7 January 2021 (UTC)[reply]
• Oppose: (1) It's not that hard to type the non-templated equivalent (2) It encourages !voting without !vote rationale, (3) It only increases the number of templates transcluded on discussion pages. Thanks! Plastikspork_―Œ^(talk) 20:03, 7 January 2021 (UTC)[reply]

  @Plastikspork, you don't ever edit from a smartphone, right? We have editors above who say that it actually is "that hard" for them to type straight apostrophes ('). I think we can trust them that they struggle with this. WhatamIdoing (talk) 23:21, 8 January 2021 (UTC)[reply]

  Then type in all caps (as suggested above), which is even easier than finding the {} symbols. Thanks! Plastikspork_―Œ^(talk) 23:30, 8 January 2021 (UTC)[reply]

  That's a good point. On my bog-standard Android keyboard ' is on the first page of symbols, { and } are on the second page. Additionally, when editing using the Wikipedia Android app there is a single button that automatically inserts the markup for bold text, there is no equivalent for templates. Unless iOS works very differently (I own no Apple products so can't check) then it seems very likely that templates being easier to insert than bold markup for smartphone users looks fallacious. Thryduulf (talk) 14:01, 9 January 2021 (UTC)[reply]

  @Thryduulf: Checking on an iphone (in a text application not in a Wikipedia app), ' is on the first page and { is on the second, but if I enter ' then the characters go back to the alphabet, while if I enter { then it stays on the second page, so it's easier to add a second {. Does android behave the same? Thanks. Mike Peel (talk) 17:31, 9 January 2021 (UTC)[reply]

  I just tried editing in the Wikipedia app on iPhone, and I see the same keyboard behavior there. Thanks. Mike Peel (talk) 17:33, 9 January 2021 (UTC)[reply]

  If there is a consensus to try to make it easier to enter bold or italic text without using a straight single quote, then I'd prefer it be done in a generic way for all text, not just specific words. Let's extend wikitext markup in some way, for example. Maybe something like @‘’’, @’’’, and other combinations of typographical quotes can be supported. isaacl (talk) 17:01, 9 January 2021 (UTC)[reply]

• This is a textbook example of a solution looking for a problem. – Teratix₵ 14:23, 10 January 2021 (UTC)[reply]

  Agreed. It's quite sad to see the amount of attention this is getting, while much more significant issues get crickets. {{u Sdkb}}^talk 15:21, 10 January 2021 (UTC)[reply]

  It's a simple solution to a problem I and others encounter regularly. I know others don't have this problem, but I am surprised at how many have gone out of their way to oppose this. Thanks. Mike Peel (talk) 16:06, 10 January 2021 (UTC)[reply]

  Mike Peel, perhaps we are not simply going out of our way, but instead many more people than expected felt strongly about this. (Similarly, User:Sdkb perhaps what you feel is significant is not the same as for others.) That does however not mean that its not a real problem, but perhaps instead that this is not the best solution. Personally, I wish I could have a panel of formatting/template shortcuts that I could customise to address a related problem I have with often forgetting specific template names (even if I use them regularly). --Xurizuri (talk) 11:33, 12 January 2021 (UTC)[reply]

  Xurizuri, significance is not some wishy-washy subjective value. Yes, assessments differ, but there are objectively things that have a big impact on readers and things that don't. The size of this discussion is perfectly indicative of our worst navel-gazey tendencies. {{u Sdkb}} ^talk 12:37, 12 January 2021 (UTC)[reply]

• Oppose per above. Likely to encourage voting behavior which would not harmonize well with enwp's consensus-based culture. -FASTILY 01:04, 12 January 2021 (UTC)[reply]
• Oppose because this method of bolding is very simple. As someone that recently began editing, the vast numbers of templates have frankly been barriers to me engaging with some parts of WP thus far, particularly when there's no immediately obvious consistency in when people use one method or the other. And trying to remember all the templates and their parameters, and type them out correctly, is one of the biggest barriers from editing resulting from my ADHD that I've had. I would greatly prefer to not have more of either of those issues. The bolding and italicising are, to me, the simplest/easiest type of formatting we've got and making that more confusing is frankly not worth it. --Xurizuri (talk) 11:33, 12 January 2021 (UTC)[reply]
• If the arguments about how very difficult it is to type straight apostrophes with a smartphone were being made in good faith, this would be a discussion about undeleting Template:Bold. —Cryptic 15:54, 12 January 2021 (UTC)[reply]
• (Restored from archive as the RfC is still active. Thanks. Mike Peel (talk) 12:57, 22 January 2021 (UTC))[reply]
• Oppose as a solution in search of a problem, and seconding Cryptic on the matter of bolding templates. Vaticidalprophet (talk) 04:59, 23 January 2021 (UTC)[reply]
• Support per SmokeyJoe's comments. On Apple mobile devices such as iPhones or iPads, it defaults to ‘, and a good half-second press is needed for ', which is very tedious and seemingly time consuming, much more than typing {{}}. This would solve all the mistakes when mobile editors try to bold text. Using <b></b> isn't any better, as you would need to switch from the default keyboard to the symbols keyboard for the "<", then go back to the default for "b", then go back for ">", then back to default for text, then rinse and repeat with an additional "/". D🐶ggy54321 ^{(let's chat!)} 04:25, 1 February 2021 (UTC)[reply]