Wikipedia:Village pump (proposals) Information

From Wikipedia
  Policy  Technical  Proposals  Idea lab  WMF  Miscellaneous 

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.

« Archives, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175

Replace hyphen with en-dash in Wikipedia browser tab name –  MediaWiki:Pagetitle

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):

MediaWiki:Pagetitle on different wikis
Wiki Separator Example of <title>
English Wikipedia hyphen Earth - Wikipedia
German Wikipedia en-dash Erde – Wikipedia
Spanish Wikipedia hyphen Tierra - Wikipedia, la enciclopedia libre
French Wikipedia em-dash Terre — Wikipédia
Russian Wikipedia em-dash Земля — Википедия
Chinese Wikipedia hyphen 地球 - 维基百科,自由的百科全书
Wikimedia Commons hyphen Earth - Wikimedia Commons
MediaWiki's own wiki hyphen Help:Editing pages - MediaWiki

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)

  • 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)
  • 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)
    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. Armadillo pteryx 00:46, 4 November 2020 (UTC)
  • Meh for; 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)
    @ 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)
    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, or Commons too - which it looks like you're not saying - then we're good. -- Floquenbeam ( talk) 23:42, 3 November 2020 (UTC)
    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)
    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)
    @ 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 (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)
    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 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)
    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)
    No worries at all! {{u| Sdkb}} talk 19:31, 4 November 2020 (UTC)
  • 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. Armadillo pteryx 00:46, 4 November 2020 (UTC)
  •  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)
Support, hyphens are not used for this purpose, WP:NDASH.   Nixinova T   C   02:23, 4 November 2020 (UTC)
  • 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)
  • Support on enwiki per Armadillopteryx. 〈  Forbes72 |  Talk 〉 16:28, 6 November 2020 (UTC)
  •  Comment: should an RFC be opened to gather more feedback? —⁠ andrybak ( talk) 16:01, 8 November 2020 (UTC)
  • Support – It shouldn't be a question that our interface should generally conform to the MOS absent any reason to the contrary. ( talk) 03:26, 9 November 2020 (UTC)
  • 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)
    • 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)
  • 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)
    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)
  • 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)
  • 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)
  • 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)
    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)
    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)
  • 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)
  • 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? -- Fuzheado | Talk 20:46, 16 November 2020 (UTC)
  •  Comment: I have requested closure of this discussion at WP:ANRFC. —⁠ andrybak ( talk) 18:25, 23 November 2020 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Oppose If it works, don't fix it. Andrew🐉( talk) 13:00, 28 December 2020 (UTC)
  • 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)
    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 &ndash;. —⁠ andrybak ( talk) 16:44, 31 December 2020 (UTC)
    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)
  • Support per MOS:ENDASH resp. Sdkb and particularly 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)
  • 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)
  • Support, per the MOS & correct punctuation. Cavalryman ( talk) 04:23, 6 January 2021 (UTC).
  • 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)
  • 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)
  • Support. MOS:ENDASH. Personally, I was quite getting used to this. Mario Jump 83! 04:32, 15 January 2021 (UTC)

RfC: What to do with category links to Commons?

What should we do with the links to Commons in categories? Mike Peel ( talk) 09:23, 12 December 2020 (UTC)

Hi all. We currently link from categories here to Wikimedia Commons categories using {{ Commons category}}. Over the last few years, we have been working on synchronizing the links to Commons categories between enwp and Wikidata, and for the Category namespace these are now fully synchronized. These links use sitelinks on Wikidata, which are robust against vandalism (a Commons category has to exist to sitelink to it), and these also match the sidebar link to Commons. They are also used to display links back to enwp from the Commons categories (both in the sidebar and the infoboxes there).

In 2018 I posted an RfC to switch to using Wikidata for interwiki links to Wikimedia Commons, which led to conditional approval to implement the changes here, and the creation of a new set of tracking categories at Category:Commons category Wikidata tracking categories. A subsequent RfC in 2019 on removing locally-defined links to Commons categories if they match the Wikidata sitelinks resulted in no consensus to remove locally defined links to Commons.

I would like to revisit this as it applies to categories only (i.e., this proposal does not apply to articles). At some future point this may also be applied to articles, but for those we need to fix the issue that causes Commons sitelinks to not appear in the sidebar (on the Community Wishlist Survey 2021), and there are ~15k articles that aren't synchronised to Wikidata yet (cases with e.g., multiple, mismatched, or misplaced links) out of 560k articles. These are not issues for links in the Category namespace, which are now fully synchronized with Wikidata.

Changes to current links

I suggest the following options for the use of {{ Commons category}}, which would only apply in the Category namespace:

A1. Remove {{ Commons category}} and just have the sidebar link. This is the easiest option to maintain here as MediaWiki will automatically display it where available. This would affect around 310k categories (the tracking categories listed in A2 and A3). An example of how the Commons link would look like after this change is Category:1817 in Vermont.
A2. Remove the locally defined links from categories, i.e., {{Commons category|Example}} -> {{Commons category}}. This is the second easiest to maintain, as e.g., renames of categories will be automatically updated. Manually defined links would only be removed where they match the Commons sitelink on Wikidata, so this would also allow local overrides. This would affect around 290k categories at Category:Commons category link is on Wikidata. An example of how the Commons link would look like after this change is Category:Data modeling.
A3. Always locally define the link, i.e., {{Commons category}} -> {{Commons category|Example}}. This is the most difficult to maintain, as it requires bot or manual edits when the link changes. This would affect around 20k categories at Category:Commons category link from Wikidata. An example of how the Commons link would look like after this change is Category:Bodies of water of Lebanon.
Adding new links

I also propose:

B. Bot-adding {{ Commons category}} where a Commons category sitelink is available on Wikidata

Many links have been added between Wikidata and Commons over the last few years (now totaling over 3 million links). If we go for (A2) or (A3) above, then bot-adding them would significantly increase the number of links to Commons. These links are already available in the sidebar, so if we go for (A1) above then this isn't needed. Mike Peel ( talk) 19:52, 11 December 2020 (UTC)

Discussion (Commons category links)

I suggest !voting for A1, A2 or A3 and saying yes/no to B. If we reach consensus for any of these options, I will code a bot to implement it and propose it at Wikipedia:Bot requests for final discussion before implementation. Thanks. Mike Peel ( talk) 19:52, 11 December 2020 (UTC)

It's not clear from the RFC as written which options would still allow us to customise the displayed text and whether we could link to multiple categories, both of which are something that arises fairly often (Commons has a slight tendency to split categories so we want to provide links to more than one, and has a very strong tendency to give categories really peculiar names which don't tally with the English common name). I'd be strongly inclined to reject any option that wouldn't allow us at minimum to add explanatory text to the link (e.g. for an biography of an architect, have one link for portraits of the subject and one link for images of their buildings, clearly labelled which is which). ‑  Iridescent 20:15, 11 December 2020 (UTC)
@ Iridescent: Those are rare occurrences in categories (but somewhat more common in articles, which is out of scope for this RfC). I can implement something for A2 that will continue to allow customised display text if really necessary, but that can easily be used to mislead the reader. Linking to multiple categories never makes sense anyway, since you can either link directly to the appropriate category from "Category:Buildings by X", or just link to 'Category:X" for the architect, and readers can then look at the subcategories on Commons for the rest - or you can improve the categories in Commons. Thanks. Mike Peel ( talk) 21:02, 11 December 2020 (UTC)
P.S., are those intentionally missing links noted/explained somewhere, please? If not, perhaps they could be noted somehow? Thanks. Mike Peel ( talk) 21:34, 11 December 2020 (UTC)

@ Mike Peel: what is your brief and neutral statement? At over 4,500 bytes, the statement above (from the {{ rfc}} tag to the next timestamp) is far too long for Legobot ( talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Wikipedia technical issues and templates. -- Redrose64 🌹 ( talk) 23:37, 11 December 2020 (UTC)

@ Redrose64: The title was kinda the summary, I've paraphrased it just below the RfC tag for the bot. Thanks. Mike Peel ( talk) 09:23, 12 December 2020 (UTC)

Just to note, I've posted a neutral note about this RfC at commons:Commons:Village_pump#Commons_links_from_enwp_categories ( diff), since this directly relates to Commons. Thanks. Mike Peel ( talk) 20:11, 12 December 2020 (UTC)

  • I'm not sure why this was bot-archived while still running, I've manually unarchived it. Thanks. Mike Peel ( talk) 13:04, 31 December 2020 (UTC)
    belated @ Mike Peel: It was archived at 02:40, 30 December 2020 (UTC) because there had been no posts since 18:17, 20 December 2020 (UTC), and the archiving settings (that's the {{ User:MiszaBot/config}} at the top of this page) include the parameter |algo=old(9d), which means that any thread which has had no new posts for at least nine days is eligible for archiving. Archiving bots cannot tell if a discussion is running or not - they simply look at the most recent timestamp. -- Redrose64 🌹 ( talk) 20:11, 17 January 2021 (UTC)

Survey (Commons category links)

  • Oppose A1 without even blinking. I'm certain 99.9% of readers aren't aware the sidebar is even there, and on a topic with a lot of interlanguage links readers are never going to see it. Weakly oppose A2 as I can't see any particular advantage to removing the ability to override the displayed label. If these are the only three alternatives then support A3, although I could accept A2 provided there were a means to override or disable it in circumstances where what's on Wikidata isn't considered appropriate. Definitely oppose B, as there are occasions when we intentionally don't link to Commons for a given subject. ‑  Iridescent 20:18, 11 December 2020 (UTC)
    @ Iridescent: As stated in the A2 description, "this would also allow local overrides". Thanks. Mike Peel ( talk) 09:17, 12 December 2020 (UTC)
  • Oppose A1 and Support A3 To always have local control over the destination of the link, makes it easier for users. Keith D ( talk) 20:30, 11 December 2020 (UTC)
    @ Keith D: Can you elaborate on how that 'makes it easier for users' please? Thanks. Mike Peel ( talk) 21:03, 11 December 2020 (UTC)
  • Concern (not opposition)... We here at WP.en have become very leery of linking to Wikidata (in any form). There are times when the two projects just don’t seem to speak the same language, and that has caused headaches for both projects. I have no idea if this is an exception or not... but please go with caution. Blueboar ( talk) 01:28, 12 December 2020 (UTC)
  • Support A1 is the easiest to maintain with the tools at our disposal and with common sense protections against vandalism. A1 is a question of getting used to it and knowing where to look. The template can have a deprecation period where it says "See sidebar left for link to Commons" to help educate during the transition period. Failing A1, would also support A2 w/ Bot add (sigh.. see how much better A1 is?). Oppose A3. -- Green C 02:38, 12 December 2020 (UTC)
    Genuine question and not being snotty, but how do you think "getting used to it" would work? In the skin in which more than 50% of readers see Wikipedia, A1 wouldn't just change the location of the link but would remove it altogether; from the perspective of readers this wouldn't be a matter of looking somewhere else to navigate to Commons, but of Commons suddenly apparently ceasing to exist. (Existing readers would probably know to ask where it had gone, but new readers would have no reason to suspect the links ever existed.) Plus, Wikipedia doesn't just have a single cohort of readers; new people discover us all the time. Most people viewing a category have either got there via a search or via the links on a Wikipedia article and aren't insiders who understand the quirks of MediaWiki, and "the links from Wikipedia pages to related content appear on that page" is a very well-established convention reinforced by 20 years of categories and navbox templates. A typical reader couldn't possibly be expected to know that if they're looking for the media associated with a category, they need to switch to desktop view if they're not already there, and then once there click a cryptic "In other projects: Wikimedia Commons" link hidden in the sidebar. ‑  Iridescent 06:40, 12 December 2020 (UTC)
    Ouch, that's a pretty major bug. I hadn't noticed that since I never use the mobile interface. I had a look on Phabricator to see if there was an existing bug report, but I couldn't find one, so I've started phab:T269992. Thanks. Mike Peel ( talk) 09:17, 12 December 2020 (UTC)
    Repeating my plug for the gadget discussed here which adds a one-click button to preview how pages will look to readers (who mostly use the mobile view) rather than editors (who rarely if ever do). You'll be astonished how many things you take for granted are either missing completely or behave completely differently (see what a mess User:Mike Peel looks in mobile view, for an obvious example). If I had my way we'd deprecate mobile view and start again from scratch—I think the current skin is irredeemably bad both for readers and for editors—but I can't imagine the WMF ever admitting that a pet project they've spent a decade promoting is a complete lemon. ‑  Iridescent 13:22, 12 December 2020 (UTC)
  • Support A1. The Commons link is just one example of the "other projects" links, and displaying them automatically as part of the user interface makes more sense than adding one or more templates to every category. If the mobile interface isn't displaying these links, then it should be fixed. Perhaps removal of the existing templates should be delayed until it's fixed. ghouston ( talk) 02:18, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 To always have local control over the destination of the link, makes it easier for users. As Keith_D put it. Or, as I put it during the last RFC: Oppose. Kerry put it well. I have long been troubled by persistent efforts for systematic bulk deletion of content from Wikipedia, in favor of obscure remote-ownership of everything by the bot-farm known as Wikidata. One of these days we need to reach a community consensus on the practice in general. Either we should transfer everything possible over to Wikidata and accept that that Wikidata is going to manage everything from now on, or we need to roll back Wikidata to tracking-categories and rare purposes of specific value. This endless struggle to roll Wikidata forwards (or backwards) one inch at a time is wasteful at best and disruptive at worst. Alsee ( talk) 16:26, 8 May 2019 (UTC) [1] A tiny number of Wikidata enthusiasts have been persistently trying to bulk-delete content screwing over other editors in a holy crusade to make Wikidata lord&ruler of all they survey. Among other problems, the typical editor is going hit CTRL-F trying to find the content they want to change, and it wouldn't be there. They maybe eventually find the would-be-completely-useless template in the wikitext, but there would be no value there. The editor is left stranded with an impossible edit, absolutely no indication anywhere WTF is going on, and no path forward. Alsee ( talk) 16:31, 13 December 2020 (UTC)
  • Support A2 and B. The typical editor does not need to edit technical interproject links. Ruslik_ Zero 20:38, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 noting that we would need to explicitly discourage well-meaning editors removing labels "because it's on Wikidata", as has already happened with the A3 example. Sometimes the difference between the Commons category name and the local name is going to be jarring, all the more so if this is used as a precedent for changing how Commons category links are presented in articles: Commons has a more worldwide focus on titling categories than any individual Wikipedia has on titling pages, and has evolved different conventions as a result, and although this doesn't arise much on categories ("in" vs. "of" Lebanon in the A3 example is barely noticeable), it will be jarring in the cases where it does matter. I've frequently created categories on Commons with different names from the Wikipedia articles, for example using a disambiguator instead of "The". On the broad issue, concur with Alsee; having what the reader sees on a page determined at Wikidata rather than on the individual project is unacceptably risky with regards to vandalism or simple error (I corrected a Wikidata description in Dutch the other day that assigned something to the wrong US state) and makes editing unacceptably difficult; "anyone can edit" is one of our foundational principles, we want readers to be drawn to correct or update something and have the satisfaction of seeing their change live, and we want those who add or expand something to fix things linked to it ( WP:SOFIXIT). Wikidata is intentionally behind a steep accessibility wall because it's a thing for information professionals and because errors there potentially affect all the projects. So I must oppose A2 and especially A1 (Iridescent's point being also hugely important regarding A1, and I am astonished the WMF was unaware of it). That said, I can see no harm in the bot run so long as we retain the ability to pipe the links when our category moves to a new title and no longer matches that at Wikidata: support B providing A3 is implemented. Yngvadottir ( talk) 21:01, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 Local control provides needed flexibility. Another aspect is language - my impression Commons tends yo make more use of local language names where as enWikipedia often uses names translated into English - more likely to cause category names to need local control. Changes other than A3 assume a 1-to-1 correspondence between Wikipedia articles and Commons Categories; there have been Wikipedia changed where I've wanted to add more than one Commons Category link. PsamatheM ( talk) 23:21, 13 December 2020 (UTC)
  • As nominator, in case it wasn't obvious, my long term preference is A1 (but that bug with the mobile site needs to be fixed first), right now I would prefer A2 since it minimises data duplication - which is the fundamental problem here. If you have multiple copies of the same data, then you have to fix each of them separately. By storing that link on Wikidata, in the same way as we store interwikis there, is the simplest option: it is then the same dataset here, on Wikidata, and on Commons (where that link is used to display the multilingual infobox). Then there are more eyes on the links, and more chance that someone will spot bad links and fix them. I'm saying this as someone that has gone through and corrected thousands of incorrect commons links from enwp over the last year.
I could live with A3 if needed, but it means continuing to bot/manually sync changes between Commons/Wikidata/here, which is just duplicate effort. Vandalism-wise, using the sitelinks/interwiki links is the safest way, since the category has to exist to be linked to (you can't change it to any random bit of text). There are currently no categories that link to multiple Commons categories, and there should rarely be a need to do that - but A2 would still let that be possible if needed. Similar with local text if really needed (but Commons category names are English by default). A tiny number of Wikidata-haters tend to trot out the same rhetoric whenever Wikidata is mentioned, which isn't really helpful (it's like arguing that all websites should go back to static rendering rather than using databases: it doesn't scale). With B, I'm happy either way - if we don't do that, I don't have to code up the bot, but we also don't get a lot more links to Commons (and bear in mind these have historically been bot-added to categories anyway). Thanks. Mike Peel ( talk) 18:05, 14 December 2020 (UTC)
  • Support A2. This is the best of both worlds option. It eliminates a need to maintain two different systems to link a WP category to its equivalent Commons category, but also allows flexibility and control in handling special cases. –  Finnusertop ( talkcontribs) 16:42, 15 December 2020 (UTC)
  • Oppose A1 unless and until the mobile view is fixed (as per the nominator). Support A2 provided it isn't seen as a step to not allowing local over-riding, which will remain necessary for all the reasons others have explained above. Peter coxhead ( talk) 17:50, 15 December 2020 (UTC)
  • Oppose A1, week oppose on A2 and support A3 for the reasons outlined by Iridescent. -- Euryalus ( talk) 23:12, 15 December 2020 (UTC)
  • Oppose A1, A2, B, - Support A3 for reasons above already given. Only in death does duty end ( talk) 15:36, 16 December 2020 (UTC)
  • Oppose A1 and A2 (very strongly), B, - Support A3 per Iri & others above. The problem with A2 is that (as I understand it) the current category links will all be removed, and the "local overides" would have to manually re-added. "Matching Wikidata" is a totally untrustworthy test. This would be a nightmare. Johnbod ( talk) 15:44, 16 December 2020 (UTC)
    @ Johnbod: The check is that the links between enwp + Wikidata + Commons are all in sync, not just 'matching Wikidata'. If you disagree with the link, then in A2 you would have to fix the link (e.g., by adding the local override, which we'd then check and correct on Wikidata/Commons - or better by fixing it on Wikidata so it's then fixed everywhere), or in A3 then you would have to fix the link (e.g., by changing the local override, which we'd then check and correct on Wikidata/Commons). Either way, the work you would have to do is very similar, it's hardly a nightmare. Reminder that enwp/wikidata is currently 100% synced for the categories we're talking about. Thanks. Mike Peel ( talk) 20:44, 16 December 2020 (UTC)
  • Weekly Oppose A1, Strongly support A2 and Strongly Oppose A3 as explained hereafter
    • Weekly Oppose A1 indeed the links to the other wikimedia projects are from my point of view not visible enough for wikipedia readers in order to lead them to click on this link in the side menu. Robby ( talk) 21:50, 19 December 2020 (UTC)
    • Strongly support A2 from my point of view this is at this moment the best solution. Robby ( talk) 21:53, 19 December 2020 (UTC)
    • Strongly Oppose A3 indeed this will result in an endless workk by both bots and manual che3ck for categories deleted respectively moved on Commons. Robby ( talk) 22:33, 19 December 2020 (UTC)
  • I generally support A1, but I think that's a question better left for a more general RFC on the boxes we put at the ends of articles. I also support A2 as a minimum result since it removes duplication of what is just another interwiki link at the end of the day, which we already accepted managing interwiki links at Wikidata. Hard oppose A3. I also oppose B as I do not want to see a continuing spread of these boxes; secondarily, enforcing the inclusion by bot of these seems to override the apparent editors' will in editing particular pages. -- Izno ( talk) 18:17, 20 December 2020 (UTC)
  • Support A2 for better visibility of the connection, but A1 is okay for me too. We should leverage Wikidata as much as possible in uncontroversial scenarios like this one. -- MarioGom ( talk) 14:16, 4 January 2021 (UTC)
  • Oppose A1, Support A2, Neutral A3, Support B. This gives the best combination of visibility and avoiding unnecessary duplication of effort. Thryduulf ( talk) 16:05, 9 January 2021 (UTC)
  • I don't care too much about A1-A3 (though I think that local definition is better, goals of en.wikipedia and wikidata do not always align and definitions are sometimes different). I however strongly oppose any automated or blind additions of the 'commons category' (and I guess that is then also an agreement with selective A1). There are many cases where commons category has nothing that is adding to our articles (all images are already used, and, albeit in rare cases, commons has less than what en.wikipedia has), and sending people off to commons to find less (or the same) than what is here is silly and just clogging our articles (especially when you get the whole series of sisterlinks). Note that commons sometimes has different croppings of 1 image, so even if the number of images on commons is higher, it still does not add. -- Dirk Beetstra T C 14:11, 10 January 2021 (UTC)
  • A3 (and A2 when the names are the same). Commons categories too often do not have names that match ours.  —  SMcCandlish ¢ 😼  08:33, 15 January 2021 (UTC)

Template:Class/icon Update

There was first a discussion on the template talk page where it was made clear that due to the number of transclusions and the protection required on each icon, that this should be brought here.

Some of the icons displayed by this template are not using the "round icon" design or are not using a specific icon at all (such as draft). I am proposing that the following icons be updated to conform with the majority. Some of these icons are also used by xTools but not by this template creating an unneeded disconnect for page classes.

  • SL-Class Article: Symbol start class.svg -> Symbol sl class.svg
  • Non-Article Page: Symbol neutral vote.svg -> Symbol na class.svg
  • Draft Page: Symbol neutral vote.svg -> Symbol draft class.svg
  • Category: Folder Hexagonal Icon.svg -> Symbol category class.svg
  • Media File Page: Video-x-generic.svg -> Symbol file class.svg
  • Portal Page: Portal-puzzle.svg -> Symbol portal class.svg
  • Project Page: Symbol information vote.svg -> Symbol project class.svg

Terasail [✉] 19:35, 31 December 2020 (UTC)

  • Sounds fine. The new icons look better to me, and bring this in line with the symbols I've seen used elsewhere. I'm not sure this needs a Village pump discussion—it's a nice bit of tidying, but it's largely not reader-facing. If we're doing work in this area, I'd like to see us focus on carrying through with the GA/FA topicon redesign, which has acquired a mandate but is now sitting at the graphics lab waiting for proposals to be submitted and an organizer to coordinate the process. {{u| Sdkb}} talk 23:58, 31 December 2020 (UTC)
  • Looks good to me. -- MarioGom ( talk) 14:08, 4 January 2021 (UTC)
  • Support. Looks like improvement, can't majorly fault any of the changes. I am a bit concerned about the minus in the non-article page icon Symbol na class.svg compared to say Symbol support vote.svg. —   HELLKNOWZ   ▎ TALK 14:22, 4 January 2021 (UTC)
  • Support. The replacement symbols indicate the information more clearly and have a more unified meaning. I agree with Hellknowz about the minus symbol for NA page, perhaps a centred dot, question or having nothing inside the border would be better? -- Xurizuri ( talk) 12:18, 12 January 2021 (UTC)
Strong support with the exception of the start-class one, which i very weakly oppose. JJP...MASTER! [talk to] JJP... master? 17:06, 13 January 2021 (UTC)
  • Support per above. ~ HAL 333 22:17, 13 January 2021 (UTC)
  • Support all seem to be improvements, though I also weakly oppose the start class one as well – I would think the orange is good for attracting attention to an article in need of expansion. Also, the icons are so small that in the proposed start class one, the incomplete bullet list idea is virtually unseeable. Aza24 ( talk) 09:24, 16 January 2021 (UTC)

Reform Category:Common vulnerabilities and exposures into rcat template

This category consists entirely of redirects at the moment. I think it would be more appropriate to rename the category to something like Category:Redirects from CVE IDs, and create a rcat template, {{ R from CVE}}, that uses it. Given the relatively small number of pages included in the category, this shouldnt be too big of a task. -- C o r t e x 💬talk 02:43, 1 January 2021 (UTC)

@ Cortex128:   Done MJLTalk 01:53, 17 January 2021 (UTC)

Convert all English variant notices to editnotices

This proposal arises from an ongoing discussion at the idea lab about how to reduce the clutter of excessive talk page banners, a phenomenon that leads to banner blindness, overwhelming and confusing new editors and reducing the visibility of the more important notices.

One idea I put out that seems to have gotten particular traction is that there is no need to have English variant notices (e.g. {{ British English}}) appear on the talk page, rather than just as an editnotice that appears in the edit window while one is editing the article. The primary rationale is that no one is policing the English variety used on talk pages, so the only place this is needed is the editnotice. I'm therefore proposing here that we convert all existing English variant notices on talk pages to editnotices on the corresponding page. This would be done via a bot task, and once completed Module:English variant notice would be configured so that it produces an error notice if placed on an article talk page. {{u| Sdkb}} talk 14:34, 10 January 2021 (UTC)

Survey (English varieties)

  • Support as nominator. To address two potential concerns: (1) In the rare instance that there's a talk page discussion about changing the variant, it's easy for the proposer to provide the context. I can't think of any other situation in which people on the talk page need to pay attention to the variant. (2) Modifying editnotices currently requires advanced permissions; my understanding is that this is for technical reasons rather than because of any editorial consensus. This is an issue that ought to be addressed on its own at some point, but I don't think it's an insurmountable impediment here, as most pages developed enough to be tagged with a variant notice are monitored by editors able to modify it, and if not, they will be prompted to create an edit request, which is quite straightforward. {{u| Sdkb}} talk 14:34, 10 January 2021 (UTC)
  • Support This is a good idea and should be implemented, provided any technical issues are addressed eventually (new permission?). GenQuest "scribble" 15:34, 10 January 2021 (UTC)
  • Support there's a dual benefit as it simultaneously improves both the talk page (by reducing clutter) and the edit screen (by displaying relevant info), a win-win. -- Paultalk❭ 16:55, 10 January 2021 (UTC)
  • Oppose The proposal seems half-baked because it doesn't address the use of templates like {{ Use British English}} which are what I see most often. For talk pages, we could use something like an infobox which would contain key pieces of information about the article such as its size and quality rating. The dialect would fit best in such a summary of the article's properties. Andrew🐉( talk) 17:26, 10 January 2021 (UTC)
    Regarding the "use" templates, this wouldn't affect them one way or another; they'll continue being available for when it's desirable to designate a variant but there's not enough erroneous editing for there to be a need for a notice. We could discuss down the line how often to have something visible vs. invisible, but for now I think getting all the visible notices into editnotice format is the best first step.
    Regarding your idea for a hypothetical talk page infobox, I'd suggest proposing that at the broader idea lab discussion. I could support it if it's implemented well, but it's beyond the scope of the more narrow change I'm trying to achieve here. {{u| Sdkb}} talk 19:12, 10 January 2021 (UTC)
  • Excellent idea. I suspect if editnotices had existed when these templates started this problem would not have arisen. Ϣere SpielChequers 18:50, 10 January 2021 (UTC)
  • Strong support if implemented, this would be huge for reducing talk page clutter, and actually making the english variety notices effective. As I said at the idea lab, the people who are disregarding or ignoring an established English variety aren't going to be on the talk page and see it there. As such, I'm convinced that the current position on the talk page is basically worthless. Aza24 ( talk) 21:03, 10 January 2021 (UTC)
  • Support this seems like a way to make the information more effective and reduce talk-page clutter at the same time. Thryduulf ( talk) 22:06, 10 January 2021 (UTC)
  • Support we do this for a few Canadian articles Template:Editnotices/Page/Canada....still not seen in mobile view :-( -- Moxy 🍁 01:06, 11 January 2021 (UTC)
  • Support great idea. One added benefit is that it reduces ownership of articles by preventing new users from posting useless engvar tags. Since only admins, template editors, and page movers can add these if we make them edit notices, it also gives template editors and page movers something to do. Wug· a·po·des 02:54, 11 January 2021 (UTC)
    • I also like the idea of removing them altogether. Wug· a·po·des 21:45, 13 January 2021 (UTC)
  • Support for all of this genre of notices (engvar, date formats etc.), but -- perhaps heretically -- I would support all top-of-the-page cleanup notices going into editnotices as well, so people who just want to consult an article for information aren't bothered with them. Beyond My Ken ( talk) 03:17, 11 January 2021 (UTC)
    Beyond My Ken, by top-of-the-page cleanup notices are you referring to things like {{ NPOV}} or {{ Original research}}? I think those notices are pretty necessary from a reader perspective, since readers deserve to know when an article has significant problems so that they can read it with due caution and skepticism (yes, people should always be doing that, but they trust us enough they de facto often don't). That's more true for some notices than others, though; I could see a case for many of the yellow style ones like {{ Cleanup bare URLs}} to be converted to be shown to editors only. The question at that point becomes whether we're wasting an opportunity to convert readers to editors by offering them an easy task. All this is tangential to the current discussion, so maybe take it elsewhere if you want to develop it further, but I hope my comment is food for thought. {{u| Sdkb}} talk 11:05, 11 January 2021 (UTC)
    No, you are correct, I was referring to the "yellow style" ones which primarily concern editors only. Beyond My Ken ( talk) 21:26, 11 January 2021 (UTC)
    I would argue that a fair number of the yellow banners are useful to readers (eg Template:Overcoloured letting colourblind users know that they may not interpret something on the page correctly, or Template:Essay-like). Further, as I've been editing even the ones which non-editor readers may not find useful now inform how I read. For example, seeing Template:Debate wouldn't have changed how I read something in the past, but now it suggests to me that people may have POV forked, there may not be great usage of reviews/meta-analyses (in the case of scientific articles), or its editing may have been a series of unconnected additions. They're also useful for the purpose of editing - I will detour from doing other tasks to correct an article if I notice some kinds of banners, including when I wasn't intending to edit it. -- Xurizuri ( talk) 10:55, 12 January 2021 (UTC)
  • Support Great idea, this banner contributes to creep and I hope that this reduces needless conflict, as many well intentioned edits from new and IP editors are related to ENGVAR. -- Tom (LT) ( talk) 03:20, 11 January 2021 (UTC)
  • Support not useful on talk pages, useful when editing which shows on editnotice. No need for new permission, nor should editing editnotices be available to all, PMR & TPE can do this. If the TPER queue becomes too long, we can get a bot with TPE to carry over additions from the talk page into the editnotice. ProcrastinatingReader ( talk) 09:21, 11 January 2021 (UTC)
  • Support per proposal ~ ToBeFree ( talk) 11:09, 11 January 2021 (UTC)
  • Support – reducing talk page template bloat and helping new editors understand Engvar at the same time sounds like a clear win-win to me. AngryHarpy talk 12:47, 11 January 2021 (UTC)
  • I think I oppose for sympathetic reasons. 2 reasons: 1) I do not think this is technically feasible. It asks to make an edit notice for essentially 6 million pages. That's an awful lot of infrastructure. (Someone tell me I'm wrong.) 2) I do think the correct remedy is removing these in their entirety from talk pages. We do not need them present in both their canonical place as article tags as well as talk pages. (Replace as needed on the article proper.) -- Izno ( talk) 14:41, 11 January 2021 (UTC)
    • @ Izno: I think it would be at most creating 41,000 edit notices with current use of the eng var module. -- Paultalk❭ 18:36, 11 January 2021 (UTC)
      • Just a casual 41k. Eyeroll. -- Izno ( talk) 18:44, 11 January 2021 (UTC)
        • Trivial for a bot. Thryduulf ( talk) 19:57, 11 January 2021 (UTC)
        • Trivial or not, a very different figure to 6 mil. -- Paultalk❭ 21:14, 11 January 2021 (UTC)
          • Creation is "trivial for a bot". Maintenance and filtering through the noise in the template namespace looking for anything but edit notices? Yeah, not so much. -- Izno ( talk) 01:39, 12 January 2021 (UTC)
  • Support This seems like a good idea worth pursuing. -- Jayron 32 18:16, 11 January 2021 (UTC)
  • Support Reducing talk page clutter is a good idea. Remagoxer ( talk) 20:51, 11 January 2021 (UTC)
  • Support. It'd be more useful as an edit notice - I know I never check first, and it's a pain to have to open the talk page in a new tab (especially as I have ADHD and sometimes forget the variant as soon as I close said tab). Ideally, similar notices about the style of writing in a given article would also be great to have as edit notices. However, a concern would be that by reducing talk page clutter, we need to not just relocate the clutter (sweeping it under the carpet, so to speak). -- Xurizuri ( talk) 10:55, 12 January 2021 (UTC)
  • Support, but what about protected pages? There might be an increase of (incorrect) ENVAR edit request, I guess you would also add a en-varent message on the talk page too? (please ping) DarthFlappy 18:53, 12 January 2021 (UTC)
    @ DarthFlappy: I would expect that the vast majority of edit requests come from people trying to edit a protected page (that they don't meet the requirements of), clicking the button to request an edit and filling in the form. You might have noticed many are blank—this is because people don't read what's on their screen and just click the big blue "Submit" (maybe thinking that they're requesting permission for them to be given edit access). But anyway, I wouldn't think the talk page banner would really make a difference on edit request content. — Bilorv ( talk) 23:49, 14 January 2021 (UTC)
  • Oppose Will only worsen banner blindness. CaptainEek Edits Ho Cap'n! 20:41, 12 January 2021 (UTC)
  • Support but not at scale, and only as a pilot. As I understand this could affect millions of articles, so please try it first as a pilot for 100s of articles. Big changes like this are best done with test cases, time passing, multiple requests for comment, and documentation. This already has my general support and also I anticipate supporting again in the future, but the proposal as it is has no limits. The scale and pace of the changes matters to me. I am only expecting volunteer-level documentation and not the best and most complete, and I encourage the pilot. I recognize the existence of the problem and feel that it will only grow. There are various possible solutions, and perhaps we have to use several solutions at once to address this issue. Please develop this one solution first. Blue Rasberry (talk) 20:51, 12 January 2021 (UTC)
  • Oppose editnotice banners are far more annoying than talk page notices. They slow down editing. Graeme Bartlett ( talk) 22:18, 12 January 2021 (UTC)
  • Oppose — Enwiki has got to be the only publication in the world that writes a single work using multiple varieties of English. Engvar isn't important enough to have talk page banners for, I agree, but the solution is to remove them altogether. Moving them to the edit notice will create edit notice blindness instead of talk page banner blindness, and that's even worse, because in theory, edit notices have the really important stuff, even moreso than talk page headers. Creating thousands or millions of edit notices is a huge overhead and maintenance increase. Edit notices are annoying and largely ignored anyway. They don't show at all for mobile users. In all, I think this moves the problem to a worse place rather than alleviating it. Levivich  harass/ hound 04:53, 13 January 2021 (UTC)
    This is a fair point. I was thinking the notice should be trimmed down, literally into a bullet point like: “* This article uses British English.”. Alternatively, we can have a single “Article conventions” talk page template which is highly trimmed down and signifies standards like the variety of English used — this assumes that there are other types of standards other than English and date variety that could possibly apply. A bit like {{ article standards|lang=British|dates=dmy}}. ProcrastinatingReader ( talk) 09:16, 13 January 2021 (UTC)
    An article conventions template sounds like a very good idea. There are probably others besides engvar and usedmy, but those two are good examples. I would find iconography to be the most efficient way of communicating these sorts of things, but I'm not sure if everyone would be on board for that. So like a little British flag somewhere if it was use BrEng, a US flag for AmEng, something like that. Levivich  harass/ hound 17:27, 13 January 2021 (UTC)
    I agree that the notices should be kept unobtrusive and concise. Regarding the "just remove them entirely" point, we already have the e.g. {{ Use British English}} family of templates, which set the standard without displaying anything, just as you describe. I'm undecided about whether/when we should use that compared to {{ British English}}, but I think that, in circumstances where it is important enough to warrant a banner, that banner should be proximate to the place it actually applies, which means putting it in the edit notice next to the article rather than the talk banners next to the talk. {{u| Sdkb}} talk 00:06, 14 January 2021 (UTC)
  • Oppose We should save banners for the truly important stuff like BLP, rather than spelling. ( t · c) buidhe 18:35, 13 January 2021 (UTC)
  • Oppose per Graeme Bartlett and CaptainEek. ~ HAL 333 22:19, 13 January 2021 (UTC)
  • Support: seems like a no-brainer. Banner blindness on a talk page is already a massive issue, and ENGVAR isn't relevant to reading the talk page, it's relevant to editing the page, so it should be where it's relevant. Sceptre ( talk) 23:33, 14 January 2021 (UTC)
  • Oppose: it's absolutely a reasonable proposal, but I'd prefer removal of these banners from the talk page instead. I just don't buy that language variant is important enough to warrant this kind of attention, and instead it will just cause reader blindness wherever it appears. I understand that it's very frustrating to be reverting the same good-faith spelling changes over and over again (I've lost count of the number of times I've had to revert "installment" back to "instalment" on the BritEng Black Mirror series of articles), but I've found that most unregistered editors will not see an editnotice, a wikicode template or a hidden comment in the middle of a word that keeps being changed (I don't know why the last doesn't work, but it doesn't), or possibly just willfully ignore them all. So I believe that this proposal, though it seems like the common sense logical position to move the template to, would just create blindness and have little-to-no effect on averting editing redundancies. — Bilorv ( talk) 23:40, 14 January 2021 (UTC)
    @ Bilorv: Your point about having to correct the same word over and over gives me a thought: what if we had an edit filter so that e.g. anyone trying to introduce "installment" to an article tagged with British English would get a big caution notice when they try to publish? {{u| Sdkb}} talk 01:58, 15 January 2021 (UTC)
    I think it is unreasonable for new/IP users to have no way of knowing this info before editing. Yes, they most likely won't read the notice, but "there's a notice that you ignored" is much better than "there's a policy hidden in our arcane (to new users) WP namespace that you don't even know about". And given that the varieties of English are largely identical, it's sometimes difficult to tell what variant the article is in; the notice is a nice reminder. - Novov T C 07:57, 15 January 2021 (UTC)
    To Sdkb, that's possibly something I could support, but I really don't like edit filters targeted at newbies because it's one more barrier to entry. If there was a way to say "literally the only changes in this edit are a bad spelling changes" then that would be ideal. I know that's asking a lot. To Mir Novov, many good faith edits I see by new/IP users that I have to revert are something I couldn't reasonably expect them to understand. There's been a discussion on the talk page? The lead doesn't mention this because of due weight? This source is unreliable even though it's a newspaper one million people read per day? It's wrong to call a section "Controversy" even though you've seen 1000 other articles with that bad heading? If anything it seems to me that "this article uses Australian English because it's about an Australian show" is so much easier to explain than most common mistakes made. — Bilorv ( talk) 09:37, 15 January 2021 (UTC)
    Bilorv, in my idealized 2030 version of Wikipedia, the way that filter would work is that someone would go in and try to make a bad switch to another variant within an otherwise fine edit, and when they click publish, a notice would pop up saying "Hey, you switched 'instalment' to 'installment', which appears to go against the British English used for this article. Would you like to (a) publish, but keep British English? [works in one click], or (b) publish anyways?"
    Even with that, though, I agree with Novov that, for pages where switches are common (which is the group we're discussing here), it's better not to make someone do all the work before giving them the alert. And it's not just newcomers—I didn't know that "installment" was one of the words that differed until you mentioned it above, so I could easily see myself making that error. Whereas if there's an editnotice that (again, thinking futuristically) automatically detects that "instalment" is used a lot on that page and therefore includes it in the examples, that'll let me know not to touch anything. {{u| Sdkb}} talk 13:05, 15 January 2021 (UTC)
  • Support - This information is most useful for actually editing pages, not discussions. Logically, it should belong there, and such a relocation would be useful to the IP editors that have "corrected" spelling . Yes, some other info is on the talk page that should be read, but a lot of people don't read that, and wishful thinking won't make that fact go away. - Novov T C 07:57, 15 January 2021 (UTC)
  • Oppose. Instruction creep, overly intrusive and will just lead to more edit notice blindness. Neutrality talk 19:43, 15 January 2021 (UTC)
  • Oppose per Neutrality. Personally, I dislike edit notices and more edit notices that would intrude on the editing interface is something that I would not want. Perhaps something similar to the Template:Use mdy dates template would be better. A whole host of edit notices on the national varities of English (sometimes where editnotices are already in place) would be worse than talk page banner blindness for content creators hoow would have to scroll past the edit notice every time they edit. Plus, the national varities of English really isn't that important and as such, this is why we should keep them on talk pages. P,TO 19104 ( talk) ( contribs) 23:08, 15 January 2021 (UTC)
  • Oppose per Graeme Bartlett and CaptainEek. Cavalryman ( talk) 03:14, 16 January 2021 (UTC).
  • Oppose. Varieties of English are not important enough to warrant placement as an editnotice. Just try and notice what variety the article is using and emulate that; if you get it wrong, someone will help you fix it. In my view, the talk page banner exists only to attempt to avert edit wars over this stuff, with one side being able to point to the banner. The rest of the time it's not useful, whether on the talk page or as an editnotice. KevinL (aka L235 · t · c) 20:07, 18 January 2021 (UTC)
    • Further to this, there are some truly important editnotices (e.g. DS notices that create blockable offenses), and the more editnotices we add the more banner blindness we get. Talk page notices are already ignored; let's not consign editnotices to the same fate. KevinL (aka L235 · t · c) 20:09, 18 January 2021 (UTC)
    Whilst I see your argument, to be fair, the editnotice format already exists right now and is placed arbitrarily; admins/TE/PMRs will place it themselves or on request for other editors, also in line with the current documentation for these templates. The pages that only have a talk notice are usually arbitrary. ProcrastinatingReader ( talk) 20:12, 18 January 2021 (UTC)
    • There's an editnotice already? That's awful. Let's delete it. KevinL (aka L235 · t · c) 20:22, 18 January 2021 (UTC)
      • Yeah, see doc of {{ British English}}. It’s done using a parameter, but the idea is (I think) to use both. To clarify, my point isn’t that we should enshrine a pattern that may not make sense, but if we don’t want language editnotices we should remove them entirely rather than the arbitrary system currently.
        Personally I think either trim it down to literally a bullet point not a hefty notice, or create a {{ article standards}} for talk pages. Each option has a different purposes of course: the former is intended to alert editors writing to tailor their language, the latter to help copyeditors ‘fix’ errors. Personally, I don’t know other varieties of English so I make my ‘errors’ and let someone else copyedit their fixes if they care, so possibly the latter is smarter. ProcrastinatingReader ( talk) 20:26, 18 January 2021 (UTC)
        • The current editnotice should be terminated with prejudice. KevinL (aka L235 · t · c) 20:52, 18 January 2021 (UTC)
          • I think I have used that edit notice. But the idea is to only insert the notice if it really needs to be noticed, ie there is a chronic problem with numerous edits on the page. So in general it should not be added in my opinion. Graeme Bartlett ( talk) 23:59, 18 January 2021 (UTC)
  • Oppose - editnotices should be reserved for important article- and page-specific instructions, and should be used as minimally as we can manage. Opening editnotices to general advisories about article styles will lead to clutter and significantly diminish the usefulness of editnotices for those article- and page-specific notices. See also this discussion from a couple years back about this exact thing which led to consensus that style notices shouldn't be used this way without evidence of disruption. In the same discussion, several users smarter than me also suggested that doing this would pollute the database with a few hundred thousand new pages and increase the loading time of articles, for no particularly important reason. Ivanvector's squirrel ( trees/ nuts) 01:04, 20 January 2021 (UTC)
    Furthermore, we still haven't solved the issue that editnotices aren't visible to mobile editors, so they're not well suited to editorial advisories anyway. Ivanvector's squirrel ( trees/ nuts) 01:06, 20 January 2021 (UTC)
  • Oppose as this proposal appears to ignore the fact that editnotices don’t show on mobile. SK2242 ( talk) 06:41, 20 January 2021 (UTC)
    Neither do talk notices. Or, well, they're well hidden. ProcrastinatingReader ( talk) 23:00, 21 January 2021 (UTC)


  • If this is adopted, how would it be implemented relative to existing editnotices that already incorporate English variety? That is, see Wikipedia:Featured articles/Editnotice templates for a list of all medical featured article editnotices, that already include English variety, incorporating a custom list of words from the article. (Not a techie, please spell this out in Dummy 101 detail.) SandyGeorgia ( Talk) 16:46, 10 January 2021 (UTC)
    • In the cases where it's already in the edit notice, I think we'd just leave it there and only remove it from the talk page. -- Paultalk❭ 17:07, 10 January 2021 (UTC)
      Yeah, for pages like Template:Editnotices/Page/Rotavirus, it already includes {{ British English|form=editnotice}}, so the bot would just remove the talk page notice and not add a duplicate. For the rare page that has a custom language editnotice, like Template:Editnotices/Page/COVID-19 pandemic, that'd be a little trickier, but still doable; the bot could just skipping adding anything for editnotices that link to a page in Category:English dialects. {{u| Sdkb}} talk 19:55, 10 January 2021 (UTC)
  • Shifting banners from talk to the edit notice helps talk but makes it even more unlikely that people will read the edit notice. I would want to see a draft of exactly how this proposal would be implemented (create a million new edit notices? create one central edit notice with magic code to show the language variety?), and exactly how it would appear. Try editing Donald Trump to see what an edit notice can look like. Johnuniq ( talk) 22:59, 10 January 2021 (UTC)
    • You're emphasis of how big of a change this will be is certainly valid, though I don't know if I agree that moving to an edit notice makes it even more unlikely that people will read the edit notice – even just the flag of the UK or US in the edit notice would do more than right now. The only alternative I can see to the current situation or the proposed solution above is to completely remove the english variety, which is a more or less impossible scenario. Aza24 ( talk) 00:10, 11 January 2021 (UTC)
    • We make the editnotice form smaller? ProcrastinatingReader ( talk) 09:25, 11 January 2021 (UTC)
      • I'm not sure how feasible this is in a technical sense, but if an editnotice template is about the formatting (eg date order), language variant, etc, then could those be smaller and all placed together right above the editor? It'd make it less obtrusive, while still being easy to locate all the relevant little pieces of information re writing conventions. Those could alternatively be in an expandable bar, like some of the category lists at the end of articles are. -- Xurizuri ( talk) 10:22, 12 January 2021 (UTC)
  • Many old time editors, most newer editors, and virtually all IPs never make it a habit to look at the talk page before editing an article page. English version notices on the talk page are worthless. GenQuest "scribble" 23:30, 10 January 2021 (UTC)
    • Completely agreed, and this proposal should address that appropriately I believe. The current placement of English variety templates are virtually invisible to the intended audience. Aza24 ( talk) 00:10, 11 January 2021 (UTC)
      • As a newer editor, I have never intentionally checked before editing so that's at least some anecdotal evidence for your point. However, I'm not sure if this is a function of the notice on the talk page, but on the visual editor on some articles there's a little prompt right under the title (eg Education in Australia). I'm a big fan of those little prompts. -- Xurizuri ( talk) 10:22, 12 January 2021 (UTC)
  • The need for an administrator to intervene will force an non-administrator-editor who notices a a change to the English variety is clearly warranted to spend two edit sessions on the page. The first session would be to place a protected edit request. The second would be to actually change the variety. Jc3s5h ( talk) 01:02, 11 January 2021 (UTC)
    • Given how infrequently a page's variety of English should be changed this sounds like a benefit to this proposal - ensuring that it only happens when there is a good reason to do so. Thryduulf ( talk) 11:12, 11 January 2021 (UTC)
      • I would agree with this. Requiring two edits isn't unreasonable for something that defines how the entire article is written. -- Xurizuri ( talk) 10:22, 12 January 2021 (UTC)
  • I expect that the opposers on the basis of "we shouldn't have them in the first place" will actually do something about that and propose that we remove them all together (were this proposal not to pass) . Otherwise, you're wasting everyone's time. Aza24 ( talk) 06:08, 13 January 2021 (UTC)
    Opposing a change from the second-best solution (talk page banners) to the third-best solution (edit notices) is not a waste of time, even if one doesn't propose the best solution (no banners). Making a proposal that doesn't have a reasonable chance of success is a waste of time. Oftentimes, "second-best" is status quo because it's the compromise. Levivich  harass/ hound 06:16, 13 January 2021 (UTC)
    You are mistaken if you believe this discussion cannot generate the consensus to remove these from talk pages without replacement. RFCs are not votes.
    Secondly, we are not wasting time regardless. We should prefer the best solution, however we get to it. It is a logical fallacy to argue that we also must do things consistent with our position, especially as this is a volunteer mission. (I have no problem being called a hypocrite if you like. :)
    Thirdly, this is maybe the least concerning thing on the wiki today. We don't need the polarism on your part. -- Izno ( talk) 22:09, 13 January 2021 (UTC)
    Izno, literally no where did I say anything like this discussion cannot generate the consensus to remove these from talk pages without replacement, and I certainly wasn't intentionally trying to generate "polarism"; the misrepresentations are not appreciated. I think I was pretty clear about what would be "wasting time" – a situation where people who oppose on the basis of "we shouldn't have them in the first place", the proposal fails, yet these opposers don't start some proposal to remove English variety banners. Because in a situation where a problem is brought up, consequently unresolved by the introduction of a bigger problem and neither end up being addressed is a waste of time. Aza24 ( talk) 22:39, 13 January 2021 (UTC)
  • Obviously, the best solution would be a bot that automatically (and quietly) corrected spelling and usage to whatever variant was designated (assuming that a variant has been designated)... with an edit summary explaining what was done and why. Then editors could simply write, and not worry about whether they were writing in the designated variant. Blueboar ( talk) 14:00, 15 January 2021 (UTC)
    @ Blueboar: editors that are writing any new content shouldn't be overly concerned with this already - it is really about avoiding refactoring the existing text over and over again. — xaosflux Talk 11:45, 16 January 2021 (UTC)
  • At the very least, the banners should be reduced and have the flags or other images removed. English varieties don't always neatly follow political boundaries, and at any rate we have WP:FLAGCRUFT for such situations in articles and yet flags are spammed across talk pages. Removing them also helps reduce space and prominence for a template that is probably mostly seen when explicitly being looked for. CMD ( talk) 16:47, 17 January 2021 (UTC)

English Wikipedia's 20th anniversary

Hello, January 15 is in two days. I see that Wikipedia:20 just has a redirect to Meta. Are there any plans to celebrate it here? -- NaBUru38 ( talk) 20:36, 13 January 2021 (UTC)

There was some talk on changing the logo for the day but they never gained much traction and ultimately fell through. Besides that, not much chatter has been going on about it on-wiki. Wug· a·po·des 21:43, 13 January 2021 (UTC)
We should at least do something... ~ HAL 333 22:20, 13 January 2021 (UTC)
Well then, let's hope it snows. Wug· a·po·des 22:40, 13 January 2021 (UTC)
  • Thanks Wugapodes for starting the RfC below. I wonder, will people clicking the logo on that date expect to be taken somewhere other than the main page? If so, do we have a decent target? WP:About certainly isn't ready, alas, but it'd be nice if we could use some of the buzz around this to direct readers toward trying out editing. Another thought is having a banner notice, or tying in the billionth edit. We're on a short timeline, though. {{u| Sdkb}} talk 23:32, 13 January 2021 (UTC)
Maybe History of Wikipedia? I don't know if it is written well enough to be "featured"... ~ HAL 333 23:42, 13 January 2021 (UTC)
Given that it's had a "needs update" banner at the top since 2018, prob. not. Maybe we could have it go to the Main page as normal, but put a variant of one of the banners like File:Wikipedia 20 cover confetti blue.png on the Main page. But that'd still leave the question of where, if anywhere, to point people who click on the banner. Maybe I'm just biased in favor of my own work, but I can't really think of any intro-esque project page other than Help:Introduction to Wikipedia that'd really be ready. {{u| Sdkb}} talk 00:31, 14 January 2021 (UTC)
That would do too. ~ HAL 333 01:12, 14 January 2021 (UTC)
@ Sdkb: I like your suggestion of linking to a version of the main page with an anniversary banner, but would this be too technical to pull off in time? I'm not convinced about Help:Introduction to Wikipedia, as it's really for people who are already interested in contributing. Just toying with an idea here, but I've always been a fan of the 'Impact of Wikipedia' video, which provides an accessible, inspiring overview, if it could be somehow linked to. If none of these suggestions are practical then I think the normal main page link is best. Jr8825Talk 12:02, 14 January 2021 (UTC)
Jr8825, a main page banner wouldn't be that hard technically; I think the harder issue would be just garnering consensus. I like that video as well, and I'd be fine linking to it from the banner. Ideally we'd want it to autoplay, but alas that might not be possible. Give me a few minutes to experiment... {{u| Sdkb}} talk 13:17, 14 January 2021 (UTC)
@ Jr8825: Does User:Sdkb/sandbox/Wikipedia:20th anniversary look something like what you envision? (It'd need attention from a CSS expert to get mobile display fully working.) To spell it out, we'd put a banner on the main page something like this, and clicking on it would lead to the page. {{u| Sdkb}} talk 14:29, 14 January 2021 (UTC)
Since we're on such a short timeframe, I went ahead and made a section below. We'll see what folks think; it'll be nice if it succeeds, and worst case scenario we just get stuck with the normal main page. {{u| Sdkb}} talk 15:25, 14 January 2021 (UTC)

Well, it seems as though there's quite a lot of active participation down below. Whatever the logo chosen, I believe it should stay for more than just one day - keep it for a week. Wilhelm Tell DCCXLVI converse | fings wot i hav dun 02:03, 14 January 2021 (UTC)

I would support that. I remember the 6 million articles banner logo lingering for a week or so. ~ HAL 333 02:20, 14 January 2021 (UTC)
  • Lingering longer than a day sounds fine to me. {{u| Sdkb}} talk 15:02, 14 January 2021 (UTC)
    I'd be fine with up to a month. — xaosflux Talk 15:44, 14 January 2021 (UTC)
    A week or two sounds good to me. A month might get tired with the flashier option (D). —  The Earwig  talk 19:21, 14 January 2021 (UTC)
    Two weeks would work well. ~ HAL 333 23:08, 14 January 2021 (UTC)
  • @ Sdkb: The WMF has a nice site set up at [2] I'm spread incredibly thin at the moment, but you might want to check it out and see if that's a worthwhile target for the banner. Wug· a·po·des 23:13, 14 January 2021 (UTC)
    Wugapodes, oh wow, I feel silly for assuming that meta:Wikipedia 20 was all there was and not thinking to check the foundation site. That's much more professional than anything we could create (my only quibble being that, alas as expected, it's more focused on getting you to donate than to edit, with the only path toward the latter being a tiny link to the Teahouse). The discussion below is unfortunately running into some disagreement about what the banner should look like, which at this late hour is probably going to result in there being nothing at all, but if we somehow find a way to get past that, pointing to the WMF page seems the way to go. {{u| Sdkb}} talk 23:37, 14 January 2021 (UTC)
    I'm trying to obtain the new video so we can switch to using that at WP:20th, but the WMF extremely frustratingly doesn't appear to have put it on Commons yet. {{u| Sdkb}} talk 02:04, 15 January 2021 (UTC)

Proposal to change logo for 20th anniversary

The result of this discussion is to change Wikipedia's logo to Option D in celebration of this project's 20th anniversary.
It is rather unfortunate that this was proposed so close to the January 15 deadline. However, despite the short time frame, there is a clear consensus in favor of changing the logo to something. (Only two editors expressed any opposition to this idea.)

As far as which logo to use, I'm afraid the community is split almost 50-50 between Option A and Option D. Because this is almost entirely based on personal preference, and this isn't really an important policy discussion, I think the fairest and most efficient method of deciding this is to simply count votes.

Details on the numbers

I started by tallying everyone's first choice votes:

  • Option A: 23 votes
  • Option B: 0 votes
  • Option C: 5 votes
  • Option D: 25 votes
  • Equal preference for A and D: 2 votes
  • Supported but expressed no preference: 5 votes
  • Oppose: 2 votes

I then eliminated all options except Option A and Option D, and I transferred the votes for the eliminated choices to those editors' second choice votes (if the editor did not indicate a second choice, then I didn't count their vote at this stage). This led to the following final tally:

  • Option A: 26 votes
  • Option D: 27 votes
Because of this, in my view, Option D is the winner. There was also some talk of adding also the fact that we just reached 1 billion edits to the logo. Reading through the discussion, there doesn't seem to be any direct opposition to the idea, although most participants were silent on the question. Accordingly, I would say feel free to include that in the logo as a matter of discretion. Mz7 ( talk) 22:22, 14 January 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should we temporarily change our logo in celebration of Wikipedia's 20th anniversary? Wug· a·po·des 22:40, 13 January 2021 (UTC)

RfC Format

Because of the short time frame, this RfC will only run for 24 hours. To ensure adequate participation in the reduced time frame, notices have been left at the administrators' noticeboard, the centralized discussion notice, and the village pumps.

The original RfC proposed File:WP20 EnWiki20 SimplifiedLogo.svg. Due to editor interest, other options have been added below and are labeled by letters. Please rank your preferences from most to least, and do not list options which you oppose.

Proposed images
The Wikipedia globe with "20 years of Wikipedia" below
A Minimal changes
A stylized Wikipedia globe with "20 years of Wikipedia" below
B In the style of the WMF campaign
A black banner with "Wikipedia 20 years of contributions by people like you"
C Inspired by the Wikipedia 10 campaign
A four panel image with a woman reading a book, a computer, a cell phone, and the wikipedia globe above the text "20 years of Wikipedia"
D First iteration in the style of the WMF campaign

Details can be found at mw:Manual:FAQ#How_do_I_change_the_logo?. Ideally a server admin can update the server configuration, but the change can also be achieved through edits to MediaWiki:Common.css

  • Support as proposer. Wug· a·po·des 22:40, 13 January 2021 (UTC)
  • Support no brainer. Levivich  harass/ hound 22:41, 13 January 2021 (UTC)
    (Thanks for the ping, Aza!) My preferences are A, C, B, D in that order. Levivich  harass/ hound 23:22, 13 January 2021 (UTC)
  • Support why not? M Imtiaz ( talk · contribs) 22:52, 13 January 2021 (UTC)
    A is my vote. M Imtiaz ( talk · contribs) 00:06, 14 January 2021 (UTC)
  • Support, sure, why not. Vanamonde ( Talk) 22:53, 13 January 2021 (UTC)
    {{rpp}} No objections to any of the images, support in the order D > C > B > A. Vanamonde ( Talk) 23:28, 13 January 2021 (UTC)
  • Support Option C, it's time. Enjoyer of WorldTalk 22:53, 13 January 2021 (UTC)
  • Conditional supportoptions since added if there are no other proposals. I'd prefer something bolder than that (which looks like it'll barely be noticeable), but I'll take it over nothing, certainly. Can we have some other proposals? {{u| Sdkb}} talk 22:55, 13 January 2021 (UTC)
  • Support - Sure, why not? Beyond My Ken ( talk) 22:56, 13 January 2021 (UTC)
    • Follow up: Of these choices, I still prefer the originally posted one, Option A. The remainder are too gaudy, or amateurish-looking, or take up too much space. I prefer the understatement of the original, which is clean and professional-looking. Wikipedia has outgrown its amateurish roots, and we should present ourselves for what we are now, the premiere source of immediate information on the Internet. Beyond My Ken ( talk) 01:19, 14 January 2021 (UTC)
  • Conditional support, same reasoning as Sdkb. Tayi Arajakate Talk 22:57, 13 January 2021 (UTC)
  • Conditional support, same as Sdkb. davidwr/( talk)/( contribs) 22:58, 13 January 2021 (UTC) Option A is better than the rest, but anything is better than nothing. davidwr/( talk)/( contribs) 23:28, 13 January 2021 (UTC)
  • Note working on getting the other options set up since there's interest. Gimme a sec. Wug· a·po·des 23:00, 13 January 2021 (UTC)
  • Support A - I prefer the fact that it is not too showy or gaudy. A nice commemoration of two decades of building the 'pedia. MarnetteD| Talk 23:01, 13 January 2021 (UTC)
  • Support If we celebrated 6 million articles, why not 20 years? ~ HAL 333 23:03, 13 January 2021 (UTC)
  • Support I want a flashing Wikipedia logo with a comic sans 20 in the middle of it and animated fireworks (preferably yellow and red, green isn't my thing) in the background. Make it happen. -- qedk ( t c) 23:03, 13 January 2021 (UTC)
  • Conditional support per Sdkb. YorkshireLad   ✿   (talk) 23:04, 13 January 2021 (UTC)
  • Support -- Enos733 ( talk) 23:09, 13 January 2021 (UTC)
Logo preference is Option A followed by option D. The logo should be changed for the anniversary. -- Enos733 ( talk) 17:58, 14 January 2021 (UTC)
  • Follow-up The RfC has changed since these first comments. Those indicating support were commenting only on option A. Wug· a·po·des 23:12, 13 January 2021 (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)
  • Option D. It's the most vibrant, but still looks professional. {{u| Sdkb}} talk 23:21, 13 January 2021 (UTC)
  • Option D As Sdkb says: Vibrant yet professional. Followed by: B, C, A. A is hardly noticeable. B is...okay but a bit hard to see what it says. C seems a bit hokey. CaptainEek Edits Ho Cap'n! 23:26, 13 January 2021 (UTC)
  • Option A makes the point in a consistent and elegant style. B and D seem too cartoony and garish. And C risks being quite inaccurate as it supposes that the readership is just like the contributors when their demographics may be quite different. Andrew🐉( talk) 23:29, 13 January 2021 (UTC)
  • Option D, then B, C, A. A seems too subtle, C perhaps too in-your-face. Thanks for the ping, Aza24! YorkshireLad   ✿   (talk) 23:31, 13 January 2021 (UTC)
  • Option D. Option A is also better than nothing. I oppose C - it looks like a Cards Against Humanity card; it's too big and the black background isn't good. power~enwiki ( π, ν) 23:32, 13 January 2021 (UTC)
Option D on Vector
  • Option D: Here is a mockup on Vector. I thought it might be too busy/colorful, but it seeing it in context – it works, I think. Fits the branding for other 20th anniversary content. Second choice: A, then B. Not C; it looks like we're protesting something or someone died. —  The Earwig  talk 23:34, 13 January 2021 (UTC)
    • Interesting mock. Maybe we need to increase the spacing between image and text a bit? ProcrastinatingReader ( talk) 08:09, 14 January 2021 (UTC)
      Yes, I think you might be right. Pad a bit more to match how the current logo looks and possibly give us enough space to properly center "20 years of"? Unfortunately we're running out of time. Ping Wugapodes. —  The Earwig  talk 19:16, 14 January 2021 (UTC)
      Working on the final designs of A and D (since those seem the only real candidates) as we speak. Should have them posted by 20:00 UTC Wug· a·po·des 19:48, 14 January 2021 (UTC)
  • D C B A ~ ToBeFree ( talk) 23:38, 13 January 2021 (UTC)
  • Option B Then D, C, A. I like the design of B and D, but D is just too busy. ~ HAL 333 23:39, 13 January 2021 (UTC)
  • D all the way The Earwig's vector changed my mind. ~ HAL 333 23:44, 13 January 2021 (UTC)
  • Option D – followed by C, I've loved the style of D since I first saw it at some WMF page; it should draw attention, worried that the others won't. A and B seem a little too bland for a celebration or anniversary imo. Aza24 ( talk) 23:40, 13 January 2021 (UTC)
  • Option A: maybe option B. C is horrible. D is messy — GhostInTheMachine talk to me 23:43, 13 January 2021 (UTC)
  • Option C, unorthodox opinion sure. In your face, yes. But it brings attention to the fact that anyone can become a contributor which is something we need more awareness of and I like its aesthetics... Tayi Arajakate Talk 23:50, 13 January 2021 (UTC)
  • Option A or C, please not the cartoony B or D. -- Yair rand ( talk) 23:52, 13 January 2021 (UTC)
  • A, then D. Not B or C. — xaosflux Talk 00:05, 14 January 2021 (UTC)
  • Option D - FASTILY 00:25, 14 January 2021 (UTC)
  • Option D then Option A. But wondering whether a logo would mention we reached one billion edits. "20 years, 1 billion edits" sounds even more grandiose. Ovinus ( talk) 00:30, 14 January 2021 (UTC)
  • Prefer A, then C, but any of these would be better than doing nothing.- gadfium 00:37, 14 January 2021 (UTC)
  • Option D (then A). I wouldn't want this around for any length of time, but it's nice and punchy (but friendly) for a day. -- Elmidae ( talk · contribs) 00:40, 14 January 2021 (UTC)
  • I really love Ovinus' suggestion of "20 years, 1 Billion edits" CaptainEek Edits Ho Cap'n! 01:10, 14 January 2021 (UTC)
Could someone with some photoshop skills modify Option D - the clear frontrunner - so that it reads that beneath the artwork? ~ HAL 333
Here it is for Option A, though I think the WIKIPEDIA portion could be moved up a tad. Ovinus ( talk) 02:35, 14 January 2021 (UTC)
I'm away from inkscape at the moment, but if we're going to have both 20 years and 1 billion edits, I would suggest they go under the Wikipedia textmark instead of over. Essentially, replaing "The Free Encyclopedia" part with something like "Wikipedia \n20 years and 1 billion edits". Another option is to keep "20 years of" above the mark and have "Over 1,000,000,000 edits" below in small caps. Wug· a·po·des 02:46, 14 January 2021 (UTC)
Good idea! I've put something similar on the right, though I admit I have no background in graphic design so the spacing may not be optimal. Maybe someone can make one using the "The Free Encyclopedia" font. Ovinus ( talk) 03:02, 14 January 2021 (UTC)
Wugapodes's suggestion, roughly
Having the text above "Wikipedia" looks much better imo. ~ HAL 333 03:18, 14 January 2021 (UTC)
A bit busy at the moment, so maybe someone else can create the analogous things for other options/Wugapodes's second idea. Ovinus ( talk) 04:09, 14 January 2021 (UTC)
I mocked up the text mark. It's at right or here. This can just be dropped into whatever logo gets chosen except C but that one's a long shot anyway. Wug· a·po·des 04:23, 14 January 2021 (UTC)
Text mark to celebrate both Wikipedia 20 and our billionth edit
  • Support A or C, preferring A. The B option has a bizarre number "2" that looks like a 5 that fell over. Both the B and D options do not match any of the look of Wikipedia or the other Wikimedia projects, so unless there is a complete rebrand everywhere, they are too strange. – Jonesey95 ( talk) 01:13, 14 January 2021 (UTC)
  • D > C > A > B > nothing. – Tera tix 01:20, 14 January 2021 (UTC)
  • D, C: Currently support D, with C coming a close second. C has the best message to deliver, and it looks really classy, but it's too solemn - maybe have some 50% opacity glyphs, or splashes of colour, on the black background to make it look less like a banner for a memorial service for a recently deceased person. Wilhelm Tell DCCXLVI converse | fings wot i hav dun 01:32, 14 January 2021 (UTC)
Comment: As Ovinus suggested, we have to mention the thing about the billion edits. How can we not? It's a milestone as great as any other, and the billionth edit itself was by Ser Amantio di Nicolao, rather than just some vandal... Wilhelm Tell DCCXLVI converse | fings wot i hav dun 02:12, 14 January 2021 (UTC)
  • Support A or D. My only strong opposition is for option C, which is too big and might be disruptive. If we can't all agree, I suggest just going for A because it's so minimal many won't even notice. 20 years is a long time... I feel like we have to advertise this milestone in some way! MusikAnimal talk 01:56, 14 January 2021 (UTC)
  • Support A'. Yes, 20 years is a benchmark that should be acknowledged, but I do not think that a dramatic celebratory change is appropriate at this moment in world history. Cullen328 Let's discuss it 02:30, 14 January 2021 (UTC)
Celebration is fun, and the whole world's beginning to look brighter every day. Vaccines are out, and economies are slowly beginning to pick up pace again. Twenty years in pursuit of excellence and a billion edits definitely call for celebration. Wilhelm Tell DCCXLVI converse | fings wot i hav dun 05:01, 14 January 2021 (UTC)
  • Support generally, first choice being Option A, second choice Option D. No objection to other options presented, though. BD2412 T 02:59, 14 January 2021 (UTC)
  • Support D though A is fine. I also support the 20 years 1 billion edits wording. Opposed to the other two. Best, Barkeep49 ( talk) 03:19, 14 January 2021 (UTC)
  • Support A, minimalism is best here. - The Bushranger One ping only 03:40, 14 January 2021 (UTC)
  • Support A, per the Bushranger. Also support mentioning the billion edits, of course. Double sharp ( talk) 04:16, 14 January 2021 (UTC)
  • Support to A or D. ‐‐ 1997kB ( talk) 04:56, 14 January 2021 (UTC)
  • First choice is Wugapodes' suggestion, second is option A, third is D and B. -- pandakekok9 ( talk) 05:02, 14 January 2021 (UTC)
  • Support D rest look meh. Oppose B and C. A looks way too bland, unlikely to even be noticed tbh. D is exciting, whilst not messy. ProcrastinatingReader ( talk) 05:55, 14 January 2021 (UTC)
  • Support D, which I thought would be too messy at first but looks great in the vector. A as backup. Vaticidalprophet ( talk) 05:58, 14 January 2021 (UTC)
  • Support D followed by A. signed, Rosguill talk 06:00, 14 January 2021 (UTC)
  • Support A D followed by D A. Also support the 20 years 1 billion edits wording Asartea Talk | Contribs 07:51, 14 January 2021 (UTC)
  • Support any: A, B, C, D. Just do something. GenQuest "scribble" 07:59, 14 January 2021 (UTC)
  • Support any, but A as first pick. -- a lad insane  (channel two) 08:11, 14 January 2021 (UTC)
  • Support option D — TheDJ ( talkcontribs) 09:06, 14 January 2021 (UTC)
  • Comment: I think many option A !voters are missing how extraordinarily subtle that change would be. It's one thing to see the extra line when you're looking at it oversized in the context of a discussion you know will be about changing it; it's quite another to be browsing Wikipedia for something totally unrelated. If we want anyone other than ourselves to notice (and I think we do for an anniversary this significant), we should choose a bolder option. {{u| Sdkb}} talk 09:30, 14 January 2021 (UTC)
  • Support C, followed by A As C doesn't seem to be getting much love, please consider A my !vote if that wouldn't win. I prefer the non-cartoony options, 20 years in, Wikipedia is into its adulting phase ;) Nosebagbear ( talk) 10:18, 14 January 2021 (UTC)
  • Support D, followed by A. The D looks quite cool. Mario Jump 83! 11:16, 14 January 2021 (UTC)
  • Support D, then A. Jr8825Talk 11:31, 14 January 2021 (UTC)
  • Support. Preferences: D or B. A is too easy to miss. –  Joe ( talk) 11:59, 14 January 2021 (UTC)
  • Support A D looks a bit cluttered and cartoonish, and I like the more simple, minimalistic form of A. B looks ugly, and C is just text.
  • Support A is the most professional looking one..lets steer clear of child like cartoons on the main page...or any page for that matter.-- Moxy 🍁 14:20, 14 January 2021 (UTC)
  • Support D Option D looks cool in my opinion, better than the rest. Danloud ( talk) 15:03, 14 January 2021 (UTC)
  • support A though it should not be temporary, it should be an alternate to main logo for a few weeks...IMO-- Ozzie10aaaa ( talk) 16:38, 14 January 2021 (UTC)
  • Support D - Compared to the other options, actually feels celebratory. D reminds of a vibrant mural on the street. Altamel ( talk) 16:51, 14 January 2021 (UTC)
  • support A, then C – B and D look amateurish. Dhtwiki ( talk) 19:47, 14 January 2021 (UTC)
  • Strong support choosing any of the proposals (though that seems to have consensus now) and I'd like C, D, B and A in that order. C is simple but thought-provoking and could inspire people to think about joining, D is beautiful and hopefully would also get people to reflect a bit on how they use Wikipedia and why, B looks nice and grabs attention and A is similar to banner themes we've used in the past and uncontroversial. — Bilorv ( talk) 19:56, 14 January 2021 (UTC)
    Just to emphasise: that's a strong support of D over A (since those look like frontrunners). Support mentioning 1 bn edits too. — Bilorv ( talk) 22:04, 14 January 2021 (UTC)
  • I support C, D, B, A, in that order. We've done bolder logos for arguably less important events, and I think C looks really good for WP 20. Best, KevinL ( alt of L235 · t · c) 20:22, 14 January 2021 (UTC)
  • Oppose, but if you must, then A looks OK. Don't forget to keep the 'The Free Encyclopedia' bit. Thanks. Mike Peel ( talk) 20:27, 14 January 2021 (UTC)
  • I thought all this was discussed and dismissed weeks ago. I agree with Mike Peel, oppose a change, but if there is to be one, A looks best.-- Wehwalt ( talk) 20:43, 14 January 2021 (UTC)
  • A only. Agreed that the professionalism on the other two is lacking. Especially if we leave this to linger for longer than the day. -- Izno ( talk) 20:44, 14 January 2021 (UTC)
  • Support any. This is a milestone worth recognizing. I would also support a "1 billion edits" message as part of the logo. — pythoncoder ( talk |  contribs) 21:23, 14 January 2021 (UTC)
  • Support the proposal: Not voting for anything specificially. Like pythoncoder I also ensorse the proposal in general. Let's do it. -- Titodutta ( talk) 22:16, 14 January 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Main page banner

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

There is some discussion above about having a banner on the main page leading to a page with some additional information and encouragement to try editing. I've put together a rough mockup of what that could look like. It needs some technical attention to get the width working properly, so apologies for not having something more refined, but I want to put it out here because we're on such a short timeframe. The main page would be changed to add a banner like this, which would lead to this page with a video and further reading/learning links (again, it still needs a few technical tweaks, and it'd of course be moved to Wikipedia:20th anniversary if adopted). Is there general support for doing something like this? {{u| Sdkb}} talk 15:22, 14 January 2021 (UTC)

I think that banner is way to big, would rather something less intrusive like we did for 6MM articles ( example). Keep in mind there is already also a huge CN banner for the New York area at the top of the page, landing on Wikipedia:Meetup/NYC/Wikipedia_Day_2021. — xaosflux Talk 15:48, 14 January 2021 (UTC)
Xaosflux, While the banner could be slightly smaller this is wikipedia's 20th anniversary and I think something big would be appropriate Asartea Talk | Contribs 15:52, 14 January 2021 (UTC)
@ Asartea: I'm assuming this would be in addition to already styling the logo special as well - that's why I'm suggesting not making it so large in addition. — xaosflux Talk 16:06, 14 January 2021 (UTC)
Support mainpage banner and the page Asartea Talk | Contribs 15:53, 14 January 2021 (UTC)
Support Good idea ....but could we incorporate a few more options like above. Just not sure a cartoonish look is apprioate during a world wide pandemic...should look more academic in my view.-- Moxy 🍁 16:01, 14 January 2021 (UTC)
Moxy, considering my quick reading of the Logo seems to indicate D will win this banner would be in the same kind of style. A more academic banner might clash with the logo otherwise. Asartea Talk | Contribs 16:08, 14 January 2021 (UTC)
Agree D will win.... the one that looks like the stickers on my granddaughters baby monitor ...sad face. Can we get color blind friendly version at least.-- Moxy 🍁 00:08, 15 January 2021 (UTC)
  • Note: There is a banner campaign planned in support of WP20 in place of the usual WMF fundraising thank you campaign and will follow a similar format to that run in previous major anniversary. Seddon talk 18:21, 14 January 2021 (UTC)
Seddon, that's good to know. I'm not sure it'd interfere with this unless it's being planned to launch tomorrow. The aim is also different if it's fundraising vs. seeking editors. {{u| Sdkb}} talk 18:32, 14 January 2021 (UTC)
  • Support ~ HAL 333 19:37, 14 January 2021 (UTC)
  • I do not support the proposed banners. I do support our usual banner like at 6m articles. Something like "Wikipedia celebrates its 20th birthday with 1 billion edits" or something. -- Izno ( talk) 20:46, 14 January 2021 (UTC)
    I agree with Izno, let's do the usual Main Page banner style like at the n-millionth article celebrations. Mz7 ( talk) 23:18, 14 January 2021 (UTC)
    I should clarify by saying I think something is better than nothing, and I merely prefer the usual banner style, but I don’t want to prevent there from being any banner at all. Mz7 ( talk) 00:00, 15 January 2021 (UTC)
  • Support, it's a bit odd to have the page icon and not a banner. As for the format of this, I'm not really sure on what would be appropriate but do support a graphical style one.
Ed talk! ✨ 23:48, 14 January 2021 (UTC)
  • There seems to be the least resistance so far to do "something" over nothing-- going off the styling at Template:Main_Page_banner - can we settle on some text, including a single bolded call to action that has a specific landing page? — xaosflux Talk 00:57, 15 January 2021 (UTC)
  • I've added the plain-ish banner via Template:Main Page banner; the landing page is Wikipedia:20th anniversary. I'm at least slightly involved in this preference, but "anything is better than nothing" seems to be prudent initially - discussion on further improvements to the banner are more than welcome to continue here and any admin is welcome to revert me if they think this is out of line without more discussion. — xaosflux Talk 02:33, 15 January 2021 (UTC)
    Xaosflux, I'm glad we managed to get something up. No one has addressed the technical stuff I mentioned above, though, so it currently works terribly on mobile or screens with an unusual resolution. Could we get someone good at CSS to address those things as soon as possible? {{u| Sdkb}} talk 12:33, 15 January 2021 (UTC)
    @ Sdkb: can you be a bit more specific? The banner seems to be displaying at least as well as any of the other page content to me at very small and very large resolutions, in vector/monobook/minerva/timeless, also via the minerva on the mobile site (en.m.wikipeida). Are you referring to the banner itself or the landing page ( Wikipedia:20th anniversary) itself (I think that one certainly could use some work but I didn't have anything to do with that page). — xaosflux Talk 18:02, 15 January 2021 (UTC)
    Xaosflux, I was referring to the landing page. BrandonXLF swooped in and fixed the issue, so we're set now. (Not the first time he's helped fix a CSS issue for mobile; many thanks!) {{u| Sdkb}} talk 18:05, 15 January 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Updated. — xaosflux Talk 19:48, 20 January 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The text of the banner current says The English-language Wikipedia is celebrating its 20th birthday! I think we should change it to Wikipedia is celebrating its 20th birthday! The founding of English Wikipedia and Wikipedia were the same, and founding Wikipedia as a whole is the bigger event, so that's what we're celebrating. Plus it's just cleaner. And I don't think we need the wikilink when this banner is appearing directly below the permanent banner which already includes a wikilink to Wikipedia. {{u| Sdkb}} talk 12:42, 15 January 2021 (UTC)

Xaosflux, courtesy pinging you on this since you implemented; would you be willing to switch the language? {{u| Sdkb}} talk 18:07, 15 January 2021 (UTC)
 Done trimmed Template:Main Page banner. — xaosflux Talk 18:15, 15 January 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

When I go to a page logged out, I see a banner with the rather silly tagline "celebrating 20 years human", linking to the WMF page. There doesn't seem to be anything on it at meta:CentralNotice; does anyone know where this is coming from? {{u| Sdkb}} talk 01:07, 16 January 2021 (UTC)

@ Sdkb: I'm not seeing that one, just the CN notice with "Thank you for making 20 year..." that has a javascript easteregg to the foundation site (sigh....). Can you inspect that element you are seeing and provide more info? Also is this on desktop, mobile, or mobile app? — xaosflux Talk 01:55, 16 January 2021 (UTC)
@ Sdkb: OK those seem to be coming from CN's as well (e.g. in pages like meta:MediaWiki:Centralnotice-template-WP20 test1 Cake20 I see the text) - think these are all being managed by User:Seddon (WMF). — xaosflux Talk 02:02, 16 January 2021 (UTC)
Variant I was originally seeing
Changed (current) variant
Xaosflux, when I just tried reloading the page, it changed the text, so we're seeing the same thing now. Attaching screenshots. If you'd like to know anything about the source code, just tell me what to look for when I inspect the element.
The main issue is that these duplicate our banner on the main page, creating some redundancy. Not a super urgent issue, but not totally ideal either. {{u| Sdkb}} talk 02:09, 16 January 2021 (UTC)
@ Sdkb: think they have a few CN's that will cycle and they also have impression diets that make them not always show, and they show on every page not just MP - don't think we should remove our MP banner just because of that. — xaosflux Talk 02:13, 16 January 2021 (UTC)
Yeah, sounds fine. It might be nice to suppress the CN banner on the Main Page to get rid of the duplication, but I don't feel strongly. {{u| Sdkb}} talk 02:21, 16 January 2021 (UTC)

This type of banner isn't really designed to be long-term, suggest taking it back down either (A) when changing to the more subtle site logo soon or (B) in about 2 weeks when we revert to the standard site logo. Any feelings one way or the other? — xaosflux Talk 19:48, 20 January 2021 (UTC)

Barring any objections, I'll stand this down whenever A occurs (see other section for progress on that). — xaosflux Talk 11:20, 22 January 2021 (UTC)

What about launching a campaign to candidate the Wikimedia Foudation for the Peace Nobel Prize?

Candidates for the Nobel Prize will be examined as from February 1st, there's still some time and this might be a favourable momentum! Lichinga ( talk) 15:47, 14 January 2021 (UTC)

  • Something like that would have to be thoroughly planned and considered. There's no chance of us being ready to launch by tomorrow. {{u| Sdkb}} talk 16:16, 14 January 2021 (UTC)
  • I agree w/ Lichinga-- Ozzie10aaaa ( talk) 17:57, 14 January 2021 (UTC)
  • This is something that would need considering in great depth, researching thoroughly and a very strong and detailed nomination prepared if there is going to be any hope of it getting past even the first sift. Another consideration is that only certain people can make a nomination and still there are around 200 different nominees a year from a much higher number of nominators. [3] So in short, not this year. Thryduulf ( talk) 22:36, 14 January 2021 (UTC)
  • Given that we're not going to win it this year, I think the nomination would be harmless. Certainly we can't prevent any eligible nominator from nominating us if they wish. BD2412 T 23:33, 14 January 2021 (UTC)

On other projects

Just wanted to note plans I've noticed at other projects. FrWikipedia are discussing the same options (except our option C) at w:fr:Wikipédia:Le Bistro du jour#Vote express d'un logo temporaire pour les 20 ans du projet. CsWikipedia chose a logo in the same art style as B and D at w:cs:Wikipedie:Pod lípou#20. narozeniny Wikipedie. Probably too late to take this into consideration, but if people are interested in being consistent with other projects, it's worth looking at. Wug· a·po·des 20:04, 14 January 2021 (UTC)

Finalizing images

Final draft of option A
Final draft of option D

Given the discussion, the main candidates are A and D (the eventual closer will need to figure out which has consensus) and there's interest in memorializing the one billion edit milestone. In prep for deployment, I've finalized these two images based on the feedback. Let me know if there are any other issues that should be fixed before midnight UTC. Wug· a·po·des 20:14, 14 January 2021 (UTC)

Given that there’s only a few hours till midnight, Wug, and also the last deployment window before Monday, do you have someone ready who can close this? And it may be worth contacting a sysadmin on IRC to have them (or someone else CR) look over the patch to make sure it, and the asset, looks okay, since there’s not much slack room I suppose. ProcrastinatingReader ( talk) 20:21, 14 January 2021 (UTC)
Chatted up #wikimedia-operations and that seems ready when the time comes. Based on feedback, it seems the deployment window isn't as tight as I first thought so we we've got a bit of wiggle room (but not a ton). Mz7 said on IRC that they're willing to close. Wug· a·po·des 21:06, 14 January 2021 (UTC)
The "20 years of" text needs to be properly centred under the puzzle-globe, it looks totally slapped on and unprofessional being slightly too much to the right. --  AxG /    21:28, 14 January 2021 (UTC)
@ AxG: I uploaded an example here, but imo it doesn't look much better. It leaves more white space between the small-cap letters and the italic text and still looks somewhat off-center because of the asymmetric width of the "W" and "A". Wug· a·po·des 21:50, 14 January 2021 (UTC)
The centered text looks slightly better to me. {{u| Sdkb}} talk 23:42, 14 January 2021 (UTC)
I disagree. The non-centered text doesn't bother me. ~ HAL 333 22:43, 14 January 2021 (UTC)
Wug· a·po·des, the final deployed logo is cut-off at the bottom on MonoBook. See comments at Talk:Main page. Fences& Windows 23:33, 14 January 2021 (UTC)
Yep, we're working on it with Seddon on IRC as we speak. I'll leave a message there as well. Wug· a·po·des 23:35, 14 January 2021 (UTC)


The logo's been up for almost 6 days now, and at this time, I believe there is consensus that the current logo ("Option D") has been up long enough. There also seems, however, to be consensus to switch the logo to Option A (i.e. File:WP20 EnWiki20 SimplifiedLogo BillionEdits.svg) for a limited time, rather than remove the logo completely. As for how long Option A should stay up, there isn't a universally agreed upon answer, with some editors suggesting 2 weeks (resulting in 20 days of changed logo total), others suggesting up to 1 year, and others advocating switching back to our standard logo immediately. However, if I were to announce a rough consensus, I would say the compromise that has the most support is to switch to Option A for the next two weeks, after which we should switch back to our standard logo. Respectfully, Mz7 ( talk) 19:02, 20 January 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

  • @ Mz7: Thanks for the close. Do we have any conclusions on the preferred duration? Up above there seems to be desire for it to be longer than a single day, but no firm consensus on exactly how long. {{u| Sdkb}} talk 22:37, 14 January 2021 (UTC)
    @ Sdkb: Unfortunately, the discussion above only focused on which logo to use, so there aren't any conclusions on the preferred duration. I would say "do what you think is right", but if you want a definitive answer, then more discussion is needed. Mz7 ( talk) 22:40, 14 January 2021 (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, per our normal deployment procedure, there shouldn't be any deploys until Tuesday, at the earliest (Monday is a US holiday so few people are around). Jdforrester (WMF) ( talk) 23:26, 14 January 2021 (UTC)
  • This doesn't happen that often, I'm good for anything up to a month. — xaosflux Talk 00:54, 15 January 2021 (UTC)
  • Two weeks would be reasonable imo. ~ HAL 333 01:26, 15 January 2021 (UTC)
    • I also support using option A for a much longer duration (up to a year) afterwards. It's subtle enough. ~ HAL 333 02:54, 16 January 2021 (UTC)
  • one month since this is a unique achievement perhaps it should stay like this one year(however I'd switch to option A)-- Ozzie10aaaa ( talk) 02:22, 15 January 2021 (UTC)
  • It shouldn't go beyond the 15th unless it is changed to a variant of the original logo. We had a rushed RfC that installed a hideously tacky logo that barely fits with Wikipedia branding, regardless if these were picked by Wikimedia. Nihlus 02:24, 15 January 2021 (UTC)
  • Two weeks to a month sounds reasonable. I absolutely opposes 24 hours. OhanaUnited Talk page 03:00, 15 January 2021 (UTC)
  • IMHO, the current logo (option D) is too distracting and loud to be used for a whole month. On the other hand, I'd be okay with having the logo up for a whole month if one of the more subtle options (e.g., option A) were used after the first 24 hours. ( talk) 03:15, 15 January 2021 (UTC)
  • I agree with the IP above that the current logo (D) is not suitable for long-term use, and with Nihlus that the 15th (or soon after) would be long enough. Two weks or a month would be too long. I wouldn't object to Option A (the original choice) replacing it for the remainder of 2021, though, since it's only a small adjustment from our regular logo. We'd then go back to the normal logo in 2022. Beyond My Ken ( talk) 04:31, 15 January 2021 (UTC)
  • I have a slightly radical suggestion - keep option D for anywhere between three days to one week, and then keep option A for one year, till 15 January 2022. Wilhelm Tell DCCXLVI converse | fings wot i hav dun 04:52, 15 January 2021 (UTC)
  • I preferred Option D, then Option A in order - as the Option D is way cooler than Option A, but I didn't realize how ugly it was until today. I agree that Option D should be used for a short while, then Option A for the rest of the year until 2022. Mario Jump 83! 04:57, 15 January 2021 (UTC)
  • 20 days for 20 years. Brightgalrs (/braɪtˈɡæl.ərˌɛs/) [ᴛ] 05:02, 15 January 2021 (UTC)
  • I agree that option D is probably not a great option for a long term logo, though I do like the idea of switching to option A for the rest of our 20th year. It shouldn't be hard to implement either as long as we can find someone to do the deployment. We've probably got this one through the weekend though. Wug· a·po·des 05:12, 15 January 2021 (UTC)
  • D only for a day as a nice joke...use A for the month.-- Moxy 🍁 05:25, 15 January 2021 (UTC)
  • I'm also liking the idea to switch to A after a bit. I don't think we need to keep D for more than a few days to a week at the most. Switch to A for the remainder of the month, or longer. —  The Earwig  talk 05:57, 15 January 2021 (UTC)
  • ~20 hours should be enough: with all these colours and everything there's hardly a need to keep it longer, people will have understood that we do indeed care a lot about this occasion. The logo File:WP20 EnWiki20 SimplifiedLogo.svg would be ok for longer periods. Nemo 06:58, 15 January 2021 (UTC)
  • No more than a week of Option D; I don't know how long celebrations will be going but they should be done by then. power~enwiki ( π, ν) 07:00, 15 January 2021 (UTC)
  • 20 days sound good. — TheDJ ( talkcontribs) 09:18, 15 January 2021 (UTC)
  • No more than a week of our painfully bright logo (fine for big splash, not a good long-runner), 72 hours would be better. Against just 1 day. Like some of the above, I'd be happy with 2-4 weeks of the calmer "A" logo. Nosebagbear ( talk) 09:50, 15 January 2021 (UTC)
  • 20 days sounds good. imo keep D for the entire duration. No opinion on whether to revert to original logo, or option A, for some period afterwards. ProcrastinatingReader ( talk) 10:25, 15 January 2021 (UTC)
  • Only 1 day seems good to me, if you must keep it longer then changing to (A) would be better for the rest of the time. Also, can we go back to 'The Free Encyclopedia' please? We're still about a factor of 1,000 from 1 billion edits, we're only at around 1000 million. Thanks. Mike Peel ( talk) 10:54, 15 January 2021 (UTC)
  • There is more than one definition of a billion. See our article. Britmax ( talk) 11:17, 15 January 2021 (UTC)
    • @ Britmax: Exactly, that's why it's best to avoid using the word. Thanks. Mike Peel ( talk) 11:37, 15 January 2021 (UTC)
      • Good point. Britmax ( talk) 11:39, 15 January 2021 (UTC)
        • One million million as a billion is supposed to be the English variant, but my English self has never heard a single person use it that way IRL, and that's not what the news, books etc. use. I'm sure it's different in different countries but I think it's predominant enough to use here. At some point you have to make a regional choice. No-one has yet suggested "100 crore", which millions (rather: tens of lakhs) of our readers would find most natural. — Bilorv ( talk) 15:16, 15 January 2021 (UTC)
          • I'm from the UK, but whenever I hear 'billion' I have to double-check what is actually meant... Good examples with crore/lakh. Why not avoid the whole issue by either just giving it as a number, or going back to the standard tagline? Thanks. Mike Peel ( talk) 18:05, 15 January 2021 (UTC)
          • Then I suspect that you, Bilorv, are rather younger than me. When I was at school in England in the 1960s and 1970s "billion" very definitely meant a million million in British English, but by the time my children went to school in the 1990s the more common meaning had become a thousand million. Some of us old codgers are still alive and reading an online encyclopedia so ambiguity should be avoided if at all possible. Phil Bridger ( talk) 18:47, 18 January 2021 (UTC)
            • Of course, the "correct" understanding of the term billion is indeed one million million. We do all know this. Sadly, we in the homeland are over-influenced by the usage of our ex-colonies and so tend to use their understanding of a billion to be a thousand million. We know that they are wrong, but the usage is spreading all over the place. Hence "billion" is likely to be a confused term for some people. I suspect though, that in this case, most people will not internalise the word billion to be a real number and will just accept that Wikipedia has done "lots" of edits. That is enough really. We have done lots, are justifiable happy about that and that is a Good Thing — GhostInTheMachine talk to me 20:32, 18 January 2021 (UTC)
  • One to a few days, I think it tends to confuse users about whether they are at the correct site. Alanscottwalker ( talk) 13:12, 15 January 2021 (UTC)
  • 1 week seems reasonable to me. My rough sense is that most people visit Wikipedia at least that often, so keeping around for that long will give everyone a chance to see it. Anything beyond that and it just gets tired. {{u| Sdkb}} talk 13:32, 15 January 2021 (UTC)
  • I wouldn't mind it being used on a permanent basis going forward. It adds some new color the site and breaks the monotony of gray and white. -- Calidum 15:35, 15 January 2021 (UTC)
  • As briefly as humanly possible. Imho this is an abomination, and I came to this page to say as much. Put the number 20 in a wreath or something if you want to celebrate "20 years", when I saw this, my first thought was that Wikimedia has finally sold out to Google. This "Silicon Valley" art style is ugly aesthetically as it is soulless. Maybe it is only fitting that Wikimedia finally wears this style on its sleeve, but it doesn't suggest a celebratory mood, at least to me. -- dab (𒁳) 19:18, 15 January 2021 (UTC)
  • The instituted icon should be up for minimal time. I think rest-of-the-month-to-20-days is a reasonable time for option A, since several seem to be suggesting that. -- Izno ( talk) 19:45, 15 January 2021 (UTC)
  • Leave D up over the weekend, switch to A on Monday. Mjroots ( talk) 20:15, 15 January 2021 (UTC)
  • Option D should only stay up until the end of the day today (24 hours from when it was implemented, whenever that is). Option A is much better, in my opinion, and I am willing to see it for up to two weeks. A whole month seems silly to me, and a year even more so. — Goszei ( talk) 21:30, 15 January 2021 (UTC)
  • Switch to A as soon as possible. D is ugly, off-brand and (to many non-American liberals) it also features a symbol of female oppression. Crazy. Rollo ( talk) 22:10, 15 January 2021 (UTC)
  • 1 day sitewide / 1 week main page. Switch to A if long-term. This is a good compromise for both the celebrators and the let's-get-back-to-work people. Cordially, History DMZ ( talk)+( ping) 00:22, 16 January 2021 (UTC)
  • I hope this won't last long. Yes, I missed my chance on !voting for another option, though I probably wouldn't have voted for any. Honestly, I first thought this was a feature letting me click on one of the four images (which are in fact one) depending on what device I was using (phone, desktop, tablet, other). As dab pointed out, these cutesy-primary-colors aesthetics don't quite cut it. --- Sluzzelin talk 00:31, 16 January 2021 (UTC)
  • I'd say 2 days for option D, then switch to option A and let it stay that way for 20 days. pandakekok9 ( talk) 03:21, 16 January 2021 (UTC)
  • comment there are about 8 editors that both would agree to change to option A and leave for a year (there are several more indicating at least a month; also one gets the feeling from reading the above posts that the majority prefer option A)... Ozzie10aaaa ( talk) 01:29, 17 January 2021 (UTC)
  • Wikipedia is for readers. Most readers couldn't care less that it's an anniversary, and the anniversary logo's visual heft is distracting. Wikipedia is for its contributors. Its contributors have spent years contributing to a site with a playful puzzle ball. Count this as another vote for "as soon as possible." (Option A is fine, but consider that many readers won't know what "one billion edits" even means. Yes, the process by which Wikipedia is made is something to celebrate, but at the end of the day, people only care if the information they're looking for is here, and whether it's right.) -- Zanimum ( talk) 15:32, 17 January 2021 (UTC)
  • If it's going to be for longer than today, we need a much wider discussion. I predict a vote of 10–1 against the current banner. To me this is a cautionary lesson about making site-wide changes without a fully representative discussion. DGG ( talk ) 18:42, 17 January 2021 (UTC)
  • Switch to Option A starting 0:00 UTC January 19 and keep Option A for the remainder of the month. Some1 ( talk) 23:55, 17 January 2021 (UTC)
  • It's time to take it down, in my opinion. ~48 hours (the time period in which it was Wikipedia's birthday in at least one time zone) would have been long enough. -- Yair rand ( talk) 00:02, 18 January 2021 (UTC)
I would say take it down at 0000 tomorrow. That's enough.-- Wehwalt ( talk) 01:41, 18 January 2021 (UTC)
  • Option D is horrible (accepted by a mere 1 vote "majority"), the sooner it is gone, the better (yesterday was too late). Pavlor ( talk) 06:16, 18 January 2021 (UTC)
  • Remove immediately I've been puzzling over the elements of the image.
strike 1: The four pictures are supposed to come from the official resources but only 3 of them do so – the mobile phone at bottom left is not part of that set, which has this instead to represent mobile usage.
strike 2: The top left image is supposed to symbolise Wikiversity, not Wikipedia. Using an icon intended for a different project seems quite erroneous.
strike 3: None of the icons created to symbolise the point of the occasion have been included – no cake, fireworks or even the number 20.
Andrew🐉( talk) 11:36, 18 January 2021 (UTC)
Switch to A ASAP. Leave A for 2 more weeks — GhostInTheMachine talk to me 11:48, 18 January 2021 (UTC)
  • Switch to A or Remove I !voted for D on the assumption that it was running for one day, because it was unsubtle enough to (hopefully) be noticed by site visitors. Agreed that's it's too flashy to stay medium- or long-term. YorkshireLad   ✿   (talk) 12:02, 18 January 2021 (UTC)
D has been on for long enough Switch to A sooner rather than later, or go back to the original. Not particularly concerned if A stays on for a month or so. · · · Peter Southwood (talk): 15:52, 18 January 2021 (UTC)
  • Switch to A I'm OK if option A stays for a while (month to year). -- Enos733 ( talk) 16:14, 18 January 2021 (UTC)
  • Switch to A asap. The current logo is nice as a special for up to a week, but if we want to do something long term, then go to A or original. — Preceding unsigned comment added by JackFromReedsburg ( talkcontribs) 00:52, 19 January 2021 (UTC)
  • I also think the current logo has run for long enough that we should switch to A. KevinL (aka L235 · t · c) 09:03, 19 January 2021 (UTC)
  • I don't edit here much anymore, but I feel like one month is long enough for a celebration like this. I'm one of the few that actually like Option D as it is a special occasion, but I'm fine with Option A if consensus reaches that conclusion. Gestrid ( talk) 14:29, 19 January 2021 (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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Duration next steps

I voted above, so need someone else to review next steps on the duration - seems like this is moving towards at least a "Change to special Logo A" soon (possibly during this weeks deployment) - though there were some concerns in another sections about the ambiguity of "billion" that may need to be addressed if we want that in the logo as well. So long as this is the next step, we've got time to determine how long "option A" will stay up once it is there, so determining that shouldn't block the switch to it if that is going to be the next step. — xaosflux Talk 16:18, 18 January 2021 (UTC)

  • would agree w/ above editor as to next step (option A asap), as seems to be the majority of editors above...(as to duration 8 editors have indicated a year, and several others about a month; since this is an achievement which will not happen again, 1 Billion, why not keep it up between a few months to a year, I guess we can vote only on duration)-- Ozzie10aaaa ( talk) 18:37, 18 January 2021 (UTC)
Huh? Option D is still here. What's going on? --- Sluzzelin talk 01:03, 19 January 2021 (UTC)
GET OPTION A UP, Pronto! Mjroots ( talk) 08:50, 19 January 2021 (UTC)
Nearly everyone working on this is a volunteer, and speaking for myself I can't exactly take another day off work to wrangle all of the stakeholders again. If swapping the logo immediately is important to you, be bold and do it; nothing I did required advanced permissions. Log on to #wikimedia-operations and ask someone to deploy option A, and if it helps point them to change 656268, patch set 1, which has option A prepped already. You can also ask an interface administrator to temporarily deploy option A using css (see MediaWiki manual) while waiting for ops to deploy the config change. Wug· a·po·des 23:14, 19 January 2021 (UTC)
@ Wugapodes: I don't think there is any "pressing need" to rush the change - and also until someone actually closes the RfC above we should be blocked on community consensus. — xaosflux Talk 01:07, 20 January 2021 (UTC)
  • If this is going to be "Change D to (anything but the default)" please make a subtask of phab:T272108 to track these together. — xaosflux Talk 15:07, 19 January 2021 (UTC)
    @ Wugapodes and Xaosflux: I've closed the discussion above and opened a subtask here: phab:T272526. Mz7 ( talk) 19:07, 20 January 2021 (UTC)
  • two weeks? (per pure math of the above 'duration' per editor it would seem at the least a month, if not more?)...-- Ozzie10aaaa ( talk) 19:36, 20 January 2021 (UTC)

margin overlap problem (resolved)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

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

Wikipedia 20-yr problem.png

"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)

I see this has already been raised above. BD2412 T 23:47, 14 January 2021 (UTC)
@ 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)
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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

image text accessibility problem

Image is being removed, so no additional work is needed on this. — xaosflux Talk 19:44, 20 January 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

@ 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)
Accessible Colour Contrast.-- Moxy 🍁 06:04, 15 January 2021 (UTC)
@ 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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

New image feedback

This is being removed, see phab:T272526. — xaosflux Talk 19:12, 20 January 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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)

  • I concur with the above. It's really distracting when trying to read articles. ( talk) 01:29, 15 January 2021 (UTC)
  • 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)
(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)
    @ Beyond My Ken: yes, temporary #Duration above is discussing how temporary. — xaosflux Talk 04:21, 15 January 2021 (UTC)
    Yes, it looks like clip art from Windows 95. Ceoil ( talk) 15:34, 15 January 2021 (UTC)
  • 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)
    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)
    Nihlus, Thanks that worked Sam-2727 ( talk) 14:28, 15 January 2021 (UTC)
  • 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)
    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)
    (Also, is anyone else super reminded of the McDonalds tagline haha?) {{u| Sdkb}} talk 12:44, 15 January 2021 (UTC)
  • 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)
  • 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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Improve tooltip for red links

If a red link is supposed to indicate that an article on that subject is needed, and is not supposed to be used for anything else, and should be removed if misused, why is the only thing you see when you place the cursor over that word "the article does not exist". Why doesn't it say "article needed"? Imagine being a living person whose name is red-linked and all you see is "the article does not exist"! Wikipedia can be so confusing when it comes to living people. Sometimes we really care about how they are treated. Could we get that tooltip (cursor message) changed?

Proposal: Change the red link tooltip to read "Article needed". -- SergeWoodzing ( talk) 17:22, 14 January 2021 (UTC)

  • Hmm, interesting suggestion. Two questions that come to mind are: (1) Would we be concerned about erroneous overuse of red links (which, like it or not, happens) leading to the software encouraging the creation of non-notable articles? (2) Is there potential for confusion by moving away from the straightforward "page does not exist" to something else? Also, we'd need to refine a bit, since redlinks exist beyond just mainspace; for instance, I'm looking at a red link to Template:Editnotices/Group/Wikipedia:Village pump (proposals) from my current edit window, an example of a page that doesn't exist and probably shouldn't exist. We'd have to handle circumstances like that before moving forward with this sort of proposal. {{u| Sdkb}} talk 17:37, 14 January 2021 (UTC)

Comment: the tooltip adds (page does not exist) to the name. Page, not article. CapnZapp ( talk) 18:58, 14 January 2021 (UTC)

I think the description should remain literal, rather than assuming that every dangling link indicates a page is needed. isaacl ( talk) 19:00, 14 January 2021 (UTC)

Much less that every red link is for an "article". — xaosflux Talk 19:05, 14 January 2021 (UTC)

"Imagine being a living person whose name is red-linked and all you see is "the article does not exist"!" Okay, I'm imagining it. My reaction? So? It simply means that no one has written about me at this time. Is that supposed to bother me? -- Khajidha ( talk) 01:23, 15 January 2021 (UTC)

To add on to what others are saying, I've occasionally seen red links for articles that have been AfDed. Needless to say, those are almost definitely not needed.- Novov T C 08:07, 15 January 2021 (UTC)

  • in practice, ti appears whenever the article is not there for any reason: this may be because the article is needed, but it an also appear because the article has never been &should never be written because it would be inappropriate to do so for any one of a variety of reasons, or because of a typographical difference or mis-spelling. In the first case, the correct way to deal with it is to write the article; in the second, to either leave it alone or remove the link, in the third case to make a redirect if it's likely to be more than just idiosyncratic. Perhaps might do well to have more specificity--but considering the possibility of misuse and confusion, we might do just a swell to let things be, and leave it to the judgment of the editor encountering the link. DGG ( talk ) 11:06, 17 January 2021 (UTC)
  • Red links, ugh. They're even using them in citations. What would it hurt to simply do away with them? If you're taking time to redlink, just create the article. We've got enough delegators on WP as it is when coupled with format tagging, etc.[ citation needed] Atsme 💬 📧 15:50, 17 January 2021 (UTC)

BLP categories

A discussion has been started at Wikipedia talk:Biographies of living persons about potential additions to the BLP policy on categories. Please join the discussion there. Thank you. — Sangdeboeuf ( talk) 23:45, 14 January 2021 (UTC)

New logo - link?

The interesting new logo that's appeared for the 20th anniversary in the top left hand corner. Why does it just link to Main page, instead of to Wikipedia:20th anniversary or [4]? -- Dweller ( talk) Become old fashioned! 12:50, 15 January 2021 (UTC)

I think for a day this is a good idea, but our Wikipedia:20th anniversary needs some polishing possibly and the link going to the metawiki page may be a bit confusing. Noting, though, that since it's now the 15th we'd have to get consensus pretty quick to implement this? How do we change the logo link, anyway? If it naturally requires a software patch I don't think we have any more backport windows till Tuesday -- possibly we can get it done sooner per this if there's consensus and a wiling sysadmin? There's also the JavaScript route. ProcrastinatingReader ( talk) 12:56, 15 January 2021 (UTC)
Side note: Isn't Java now deprecated? GenQuest "scribble" 19:11, 16 January 2021 (UTC)
Java != JavaScript. And, Java is certainly not deprecated, though its use as a web applet language has diminished for various reasons. You may be thinking of Flash, which is effectively dead as of this month. -- Izno ( talk) 19:33, 16 January 2021 (UTC)
Yes, that was it. Thanks. GenQuest "scribble" 19:43, 16 January 2021 (UTC)

Delete Gadget and Gadget Definition namespaces

The Gadget and Gadget Definition namespaces are unused, have never been used, and have confusing documentation at Wikipedia:Gadget due to having never been used. Apparently, all relevant gadgets are in MediaWiki-space (for example, MediaWiki:Gadget-Twinkle.js). Considering this, there is no reason to keep the namespaces around.

Somewhat relevant:

If after five years nothing has happened, I doubt anything will happen with the namespace in the future. Elliot321 ( talk | contribs) 20:25, 15 January 2021 (UTC)

.mw-advancedSearch-namespace-2300, .mw-advancedSearch-namespace-2301,
.mw-advancedSearch-namespace-2302, .mw-advancedSearch-namespace-2303 {display:none !important;}
  • Strong support, especially gadget definition, which is literally comprised in a single page: MediaWiki:Gadgets-definition. JJP...MASTER! [talk to] JJP... master? 21:12, 15 January 2021 (UTC)
    I'm not sure what you mean by this. That page is where the current gadgets are defined, so would be unaffected by this change. What would be removed are the namespaces above, which are currently entirely unused, but in theory would be by the future gadget reorganization. ~ Amory ( utc) 22:44, 17 January 2021 (UTC)
    Amorymeltzer, what I mean is that the gadget definition namespace is entirely useless, because what it would be supposed to contain is in that single page. JJP...MASTER! [talk to] JJP... master? 18:19, 18 January 2021 (UTC)
  • Please note that I requested gadgets improvements, including parts of Gadgets 2.0, in the most recent community wishlist, see m:Community Wishlist Survey 2021/Bots and gadgets/Gadgets improvements. This may be addressed by the community tech team in the coming year. -- DannyS712 ( talk) 05:22, 16 January 2021 (UTC)
    I'll withdraw this proposal if there's actual work on gadgets. I don't have a gripe with the namespace, I just didn't get the impression it was ever going to be used at this point. Elliot321 ( talk | contribs) 07:56, 16 January 2021 (UTC)
  • I’m still yet to see many valid usages of this namespace as an article title, other than one popular redirect example, possibly two. ProcrastinatingReader ( talk) 08:15, 16 January 2021 (UTC)
    I see it has been added to the RfC list. Can someone clarify if it within the domain of community consensus to even remove the namespace / gadget, and if so is it even a good idea if that Wishlist proposal will happen? If no to either, then RfC is likely a waste of time. ProcrastinatingReader ( talk) 18:41, 16 January 2021 (UTC)
    I think it falls under WP:CONEXCEPT. -- Izno ( talk) 19:32, 16 January 2021 (UTC)
    @ ProcrastinatingReader: As I understand it, adding or removing a namespace is something that only developers can implement, and they will (again AIUI) only do so in two circumstances (1) where it is (no longer) required for a new (or removed) software feature, or (2) clear community consensus. Regarding the Wishlist proposal, it is almost impossible to predict which of the proposals will be actually be worked on beyond investigating in more detail what that work would entail and what resource is required. If there is no clear indication on Phabricator after about 3 months then I'd say to ask for an update, but before that point it's unlikely to be worthwhile even asking. Thryduulf ( talk) 03:45, 17 January 2021 (UTC)
  • Support* *unless there's work on the namespace, as DannyS712 indicted might be coming. ~Gwennie🐈💬  📋⦆ 22:00, 16 January 2021 (UTC)
  • Notified: Template:Centralized discussion. – MJLTalk 17:29, 17 January 2021 (UTC)
  • I'm not clear on what the point of this RfC is. There's only one page in any of these namespaces (i.e. Gadget:Invention, Travel, & Adventure), and AFAIK, it cannot be modified or deleted by anyone on enwiki without at least steward--if not sysadmin--intervention (which itself is why it exists, as a one-off hack). Is the intent to establish a consensus first, and then open a phab ticket or something to ask for the removal of the namespace by developers, using this RfC as evidence of consensus? I think that would be a platform-wide change, wouldn't it? If so, wouldn't we need more than just enwiki to agree with that before the devs would even begin to listen? I ask because we've been here before, last year, and nothing came of it, and I'm not sure what this RfC would change about that. Writ Keeper  17:42, 19 January 2021 (UTC)
    Writ Keeper, if that's the case then should this be a Meta RfC? JJP...MASTER! [talk to] JJP... master? 23:06, 19 January 2021 (UTC)
    @ Writ Keeper and JJPMaster: I don't think that removing these namespaces would be a platform-wide change given that different wikis can have different namespaces, although it's possible it might be. If it is possible, the developers will not remove the namespace here without evidence of consensus to do so. If it isn't consensus to remove it only on en.wp would be evidence of a good reason to start a discussion on meta. Thryduulf ( talk) 12:05, 21 January 2021 (UTC)
    @ Thryduulf: Generally speaking, yes different wikis can have different namespaces. But my understanding--which is limited for sure--is that these aren't just extra namespaces the way Draft is. The Gadget: and Gadget definition: namespaces are reserved by the Gadgets 2.0 extension, so I think removing the namespaces would require a code change for that extension, which would impact all wikis.
    My point isn't ultimately about whether this should be here or on Meta, although that is a pending question. My point is that--again, based on my limited knowledge and unlike a normal modification of namespaces--this is a non-trivial code change that will impact all wikis, not just enwiki, and it's one that the devs have already repeatedly refused to do. (Why we even have a half-finished extension on a production site is another question entirely, but...) I don't think this RfC is formulated in a way that people know what they're asking for, and as such, I don't think it'll go anywhere, even if we get a consensus. Writ Keeper  14:41, 21 January 2021 (UTC)
  • Support Never used, only use I have seen is Gadget:Invention, Travel, & Adventure, which is only in that namespace because of the format of the subject title. Semi Hyper cube 13:44, 20 January 2021 (UTC)
  • Support. Having this sort of thing around contributes to complexity and confusion and, as mentioned, this namespace is only used once. I have always wondered what the point of this namespace was / is and can see now others are in the same boat. With respect to our jurisprudence I think it's perfectly fine to indicate that locally on EN WP we don't see this namespace being useful, and further discussion can happen at a larger venue. Many such technical changes have arisen from discussions locally that indicate the feeling of editors, even if there may need to be other discussions elsewhere. -- Tom (LT) ( talk) 07:03, 21 January 2021 (UTC)

Rename Trecento/Quattrocento/Cinquecento/Seicento/Settecento categories

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The following categories should, in my opinion, be replaced with their plain English equivalents:

The English titles are way more informative. Someone who doesn't know the Italian art of this period won't have to guess what Seicento means. It's worth noting that not even the Italian Wikipedia uses this rather cryptic convention: it:Categoria:Compositori italianicapmo ( talk) 14:01, 18 January 2021 (UTC)

Capmo, I'm inclined to agree, but I think you want to post this at WP:CFD: the "D" is for "Discussion", not just "Deletion". :-) YorkshireLad   ✿   (talk) 14:22, 18 January 2021 (UTC)
Oh, thanks YorkshireLad! I was looking for that exact page, but couldn't find a link to it anywhere on the Community portal or the Village pump. Should I delete this topic from here and create another there? — capmo ( talk) 14:51, 18 January 2021 (UTC)
On a second thought, WP:CFD doesn't seem to be the best place for longer discussions. I created a new entry at WP:CATP instead. — capmo ( talk) 15:11, 18 January 2021 (UTC)
Capmo, Fair. :-) YorkshireLad   ✿   (talk) 15:24, 18 January 2021 (UTC) I'll mark this as closed. YorkshireLad   ✿   (talk) 15:24, 18 January 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Before deleting articles make a consensus

Explained below. — xaosflux Talk 19:50, 20 January 2021 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

This is for administrator deleted articles(speedy deletions) not AFD. That way people can discuss deleted articles before they can be deleted. That way hours of work doesn't get ruined.

I know it says somewhere that it doesn't matter how much time or effort it took to make articles but this would really be helpful for some. SoyokoAnis 03:50, 19 January 2021 (UTC)

That's why it's called speedy deletion. You can discuss it afterwards on the admin's talk page or at WP:DRV. Also, no work is lost because any content can be restored (you can ask any admin for a copy, or the page can be restored either as an article or draft at DRV). –  Finnusertop ( talkcontribs) 05:23, 19 January 2021 (UTC)
@ Finnusertop:, okay! I didn't fully understand it. Thanks! SoyokoAnis 21:58, 19 January 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Should Cewbot remove interlanguage link templates once local articles exist?

This task ([ [5]]) destroys the information about which other wikis have relevant articles about the subject. For instance, if the article is created, and then one week later is deleted again, the {{ ill}} link is gone and the work of the editor who originally placed it there is lost.

The reason for this odd behavior has been that the bot is computationally intensive. Now, the bot was recently given the ability to bypass this load. The idea is that an editor adds |display=force to the {{ Interlanguage link}} when the English article exists. The template will then render as a regular blue link but retain the information about other wikis, so if that article is deleted, an editor can simply turn off the |display= parameter again. Of course, the bot itself should be this editor.

Another reason brought up is that {{ ill}} create clutter in the editing window, but I see nothing worse than when you have a load of references interspersed in running text.

One argument is also that Cewbot waits one week before removing the {{ ill}} links. But articles quite often take more than one week to go through PROD or AfD.

So should Cewbot remove interlanguage link templates once local articles exist?

I say there's gotta be a better solution that doesn't destroy the work of editors. CapnZapp ( talk) 10:47, 22 January 2021 (UTC)

I should add that I brought this up at the bot's talk page but was shut down twice and told the Bot Noticeboard was a more appropriate place to have this discussion. Then that discussion was shut down and I was told to go to the Village Pump. So far I've complied, but this is the end of the line.
User talk:Kanashimi/Archive 1#Task 1 Convert interlanguage link templates with local article to wikilinks

CapnZapp ( talk) 10:51, 22 January 2021 (UTC)