Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

Jump to navigationJump to search
Policy Technical Proposals Idea lab WMF
Miscellaneous
Table of contentsFirst discussionEnd of pageNew post
Shortcuts
WP:VPR
WP:VP/PR
WP:VPPRO
WP:PROPS
New proposals are discussed here. Before submitting:

Check to see whether your proposal is already described at Perennial proposals. You
may also wish to search the FAQ.
This page is for concrete, actionable proposals. Consider developing earlier-stage
proposals at Village pump (idea lab).
Proposed policy changes belong at Village pump (policy).
Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject
Council/Proposals.
Proposed new wikis belong at meta:Proposals for new projects.
Proposed new articles belong at Wikipedia:Requested articles.
Discussions or proposals which warrant the attention or involvement of the
Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
Software changes which have consensus should be filed at Phabricator.
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

Centralized discussion

Village pumps:policy•tech•proposals•idea lab•WMF•misc

Reliability of Business Insider reporting
Referring to creators credited under a deadname
Meta: Initiatives of recommendations
For a listing of ongoing discussions, see the dashboard.
viewedithistorywatcharchivetalkpurge

Contents
1 Replace hyphen with en-dash in Wikipedia browser tab name –
MediaWiki:Pagetitle
2 RfC: What to do with category links to Commons?
2.1 Discussion (Commons category links)
2.2 Survey (Commons category links)
3 This is alarming.
4 Template:Class/icon Update
5 Reform Category:Common vulnerabilities and exposures into rcat template
6 RfC: Should we have Support/Oppose/etc. survey convenience templates?
6.1 Survey (survey convenience templates)
7 Allow linking to the "submitted" draft article available for review
8 Bring back Superprotect protection
9 Blocking Request for User:IN

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. Armadillopteryx 00:46, 4 November 2020
(UTC)
Meh for en.wiki; they're all just horizontal lines. 99% of users have never
noticed, and of that 1%, 96% won't care. None of our business for all other wikis.
I assume I'm misunderstanding Sdkb's comment; you aren't suggesting that the result
of a discussion here should affect all other wikis? --Floquenbeam (talk) 23:29, 3
November 2020 (UTC)
@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, es.wiki
or Commons too - which it looks like you're not saying - then we're good.
--Floquenbeam (talk) 23:42, 3 November 2020 (UTC)
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
https://en.wikipedia.org/wiki/Earth?uselang=de (an en.wp page but with the
interface language set to German). The second item in the "contribute"/"Mitmachen"
section is the custom English "Learn to edit" in both English and German interfaces
rather than the default "Introduction" / "Einführung". Thryduulf (talk) 01:41, 4
November 2020 (UTC)
You can see what impact changing the interface language would have by appending ?
uselang=xx (where xx is the language code you want to use) to the URL (or
&uselang=xx if the URL already contains a ?). For example go to
https://en.wikipedia.org/wiki/Earth?uselang=de to see an English Wikipedia article
with the interface language in German. The article text remains in English, but all
the tabs, sidebar links, etc. are in German. Thryduulf (talk) 01:41, 4 November
2020 (UTC)
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. Armadillopteryx 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. 207.161.86.162 (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 207.161.86.162 and SMcCandlish,
who both expressed my view very succinctly. Similar to The Earwig, I was wavering
for some of the same reasons, but above all because of GhostInTheMachine's
statement. However, my support was strenghened when I saw that a significant
portion of the Oppose votes were because of a fear that something could break,
which is absurd IMO given andrybak's point that the title already often contains
non-ascii characters. ◅ Sebastian 20:38, 1 January 2021 (UTC)
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)
RfC: What to do with category links to Commons?

Dialog-information on.svg
Internet-group-chat.svg Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page
has been added to the following lists:
Wikipedia technical issues and templates
Wikipedia proposals
When discussion has ended, remove this tag and it will be removed from the lists.
If this page is on additional lists, they will be noted below.
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)
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. -- GreenC 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 (talk ⋅ contribs) 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)
This is alarming.
See these:

https://www.eff.org/deeplinks/2020/12/disastrous-copyright-proposal-goes-straight-
our-naughty-list
https://torrentfreak.com/us-passes-spending-bill-with-case-act-and-felony-
streaming-proposal-201222/
https://www.techdirt.com/articles/20201222/09404045933/senator-tillis-releases-
massive-unconstitutional-plan-to-reshape-internet-hollywoods-image.shtml
I think WP should do a blackout, and also lock up the site (disable access to
upload, download, and to view content pages, but not deleting them) unil this is
protested. The notice and staydown regime pretty much tells sites to “police
harder” which is impossible at scale else they'll be sued. — Preceding unsigned
comment added by Joeleoj123 (talk • contribs) 23:00, 22 December 2020 (UTC)

Oppose Keep politics out of Wikipedia. If you want change, write to your
congressman and sentator. RudolfRed (talk) 23:45, 22 December 2020 (UTC)
But see Stop Online Piracy Act#Wikipedia blackout. Tony Tan · talk 08:32, 27
December 2020 (UTC)
Oppose. Wikipedia should act if and only if three conditions are met: a) that it
materially affects Wikipedia now or in the predictable future, b) that it is
politically feasible to stop, and c) that Wikipedia's action might be influential
on the result. My understanding is that neither (b) nor (c) apply because it's part
of an omnibus spending bill that's already passed Congress, and although I am
ignorant enough of the specifics enough to be agnostic about (a), I'm not certain
it applies either. I don't like the result here, but I don't think this is one of
the few cases where Wikipedia should intervene. {{Nihiltres |talk |edits}} 00:48,
23 December 2020 (UTC)
Joeleoj123, this is a fait accompli. Dont see the point in blacking out. If it
becomes a problem we can move the encyclopedia. —TheDJ (talk • contribs) 11:36, 23
December 2020 (UTC)
@Nihiltres and TheDJ: You seem to be confusing the CASE Act and felony streaming
bill (both of which indeed look like faits accomplis at this point) with Senator
Tillis' proposed Digital Copyright Act. The latter looks much more far-reaching
(involving major changes to the DMCA, which Wikipedia and Commons rely on heavily)
and is still very much up for discussion, as the EFF post linked above stresses
("This proposal is far worse than SOPA/PIPA, so our coalition will have to be
stronger and more united than ever before"). Regards, HaeB (talk) 13:52, 27
December 2020 (UTC)
The proposal to charge felony for copyright infringement doesn't apply to us.
However, the section 230 reform does affect us. The Wikimedia Foundation has
already taken measures about it, and I would support a blackout on it. --NaBUru38
(talk) 12:22, 29 December 2020 (UTC)

Wikipedia is not a platform for political advocacy. ~ ToBeFree (talk) 23:52, 30

December 2020 (UTC)
Even if it is to protect & further our ability to collect & present free
information? -- llywrch (talk) 01:11, 31 December 2020 (UTC)
Yes. ~ ToBeFree (talk) 02:41, 31 December 2020 (UTC)
Oppose until someone can show us that the final text is an existential threat to
Wikimedia projects. --MarioGom (talk) 14:11, 4 January 2021 (UTC)
Oppose, obviously. "disable access to upload, download, and to view content pages"
-- literally the opposite of Wikipedia's purpose. — HELLKNOWZ ▎TALK 14:17, 4
January 2021 (UTC)
Oppose per Nihiltres. I would support adding Wikipedia should act if and only if
three conditions are met: a) that it materially affects Wikipedia now or in the
predictable future, b) that it is politically feasible to stop, and c) that
Wikipedia's action might be influential on the result. to a guideline or essay
somewhere. — Wug·a·po·des 22:24, 4 January 2021 (UTC)
no...nO...NO...NO! and, once again, NO! GenQuest "scribble" 20:57, 7 January 2021
(UTC)
Oppose. Did we mention NO? Wikipedia is apolitical and should never be used as a
platform for political advocacy regardless of issue. I would apply this even to
"existential threats" – if the project's continued success is so tenuous that it
rests on messages delivered via its encyclopedia, it's probably not worth saving. I
strongly doubt that it is. Leave the politics to the WMF. ―Mandruss ☎ 21:30, 7
January 2021 (UTC)
Oppose. The situation around SOPA (which was an existential threat to Wikipedia)
should be the bare minimum for a blackout. As much as it might seem tempting to
join the latest outrage about misbegotten-Internet-law du jour, politicising
Wikipedia so blatantly would sacrifice what goodwill we have unless it is literally
a matter of "We can't function if this passes". As noted above, the more troubling
parts are still up for discussion in any case, so discussion of any sort of
blackout is premature at this point. Legislatures not debating a crisis move at the
speed of smell. —A little blue Bori v^_^v Takes a strong man to deny... 22:01, 7
January 2021 (UTC)
Template:Class/icon Update
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 disconect 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)
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)

RfC: Should we have Support/Oppose/etc. survey convenience templates?

Dialog-information on.svg
Internet-group-chat.svg Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page
has been added to the following lists:
Wikipedia proposals
Wikipedia policies and guidelines
Wikipedia technical issues and templates
When discussion has ended, remove this tag and it will be removed from the lists.
If this page is on additional lists, they will be noted below.
Should we have survey convenience templates? Mike Peel (talk) 22:07, 1 January 2021
(UTC)
While WP:NOTVOTE is really important, we
this one) that people Support/Oppose and
projects use templates like {{Support}},
also including a symbol. These templates
because people objected to the inclusion
have a lot of discussions/debates (like
comment on. A lot of the Wikimedia
{{Oppose}} etc. to help with this, often
were deleted here back in 2005, mostly
of the symbol.

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

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

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

Survey (survey convenience templates)

{{Support}} as proposer. Thanks. Mike Peel (talk) 22:07, 1 January 2021 (UTC)
Oppose As I would typically say in TfD, insufficient complexity of markup to
warrant a template. I completely fail to see the point of creating a template whose
content is its name with three apostrophes prepended and appended, when that is
only two characters longer than typing the wikitext out in the first place. *
Pppery * it has begun... 22:27, 1 January 2021 (UTC)
Notified: Wikipedia talk:Templates for discussion. * Pppery * it has begun...
22:31, 1 January 2021 (UTC)
@Pppery: It's not about the number of characters, it's about the time it takes to
remember the syntax, and that the syntax shouldn't depend on which Wikimedia
project you are using. The human cost is much more than the syntax cost. It's the
same as {{tq}} vs. this alternative way of writing it. Thanks. Mike Peel (talk)
22:38, 1 January 2021 (UTC)
I would prefer to type “ {{Support}}” rather than “'''Support'''” because the “'”
character is not on the iPad keyboard. {{Support}} could be made to auto-subst.
Oppose cut or gaudy pictures. —SmokeyJoe (talk) 23:05, 1 January 2021 (UTC)
my iPad allows me to type a '. Switch the keyboard to punctuation, then press and
hold the ‘ key. The pop up menu offers you 4 differs types of quote symbol —
GhostInTheMachine talk to me 23:36, 1 January 2021 (UTC)
That was a nice trick to learn! Thank you. Unfortunately, it is very tedious to do
the six times. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
or just type Oppose, select the word and click the B on the editing toolbar —
GhostInTheMachine talk to me 23:48, 1 January 2021 (UTC)
Yeah that works. Unfortunately, the toolbar is above the fold. I wish it could be
moved to below the editing window. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
Or you could just try convincing people using words instead of syntax. —Cryptic
06:39, 2 January 2021 (UTC)
I like the simple bold of the lede word of the !vote. Do you dislike that low level
of syntax? This !vote bolding culture underlies the working of
https://afdstats.toolforge.org/, which is sometimes a nice tool. --SmokeyJoe (talk)
07:00, 2 January 2021 (UTC)
One possible work around is to use iOS's text replacement feature (Settings ->
General -> Keyboard -> Text replacement). You can choose any sequence of characters
to be replaced by another. For example, you could choose bqq to turn into '''
(three single quotes.) isaacl (talk) 20:23, 9 January 2021 (UTC)
Oppose Sorry but no. I understand that moving between projects is a mental pain (I
struggle with the equivalent of {{tl|xxx}} at Commons) but hiding simple syntax
does not help the project. Some projects appear more focused on a vote count, and
that idea should not be encouraged here. Johnuniq (talk) 23:08, 1 January 2021
(UTC)
Oppose per Johnuniq's comments, especially about hiding syntax. We should not be
encouraging anything that gives the impression that votes are more important than
the rationale accompanying them. Thryduulf (talk) 23:14, 1 January 2021 (UTC)
@Thryduulf: How exactly does the existance of a convenience template give that
impression, please? Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)
@Mike Peel: the existence of a template, regardless of the formatting it outputs,
elevates the importance of that output - if it wasn't important then why would
anybody make a template for it? Why would any template be kept if it wasn't adding
something of value? Experienced editors will unlikely gain this impression, but
that is not necessarily true of those who are new to Wikipedia or who have a
limited understanding of how XfD discussions work (if there wasn't an impression
they are votes then we wouldn't need boilerplates like {{not a vote}}). Thryduulf
(talk) 23:57, 3 January 2021 (UTC)
I disagree with that thinking, I don't think having the template would give any
more weight to a new user's thinking that they can !vote than seeing a list of
bold-formatted support/oppose votes that they could copy/paste would. Thanks. Mike
Peel (talk) 09:30, 4 January 2021 (UTC)
Oppose what would the Support template expand to, other than Support in bold? —
GhostInTheMachine talk to me 23:45, 1 January 2021 (UTC)
I would have the string {{Support}} auto-change and substitute to '''Support'''. I
would find it useful, for the same end result. --SmokeyJoe (talk) 04:34, 2 January
2021 (UTC)
weak support I don't think it unreasonable request--no reason to make anyone's
editing harder and it sounds like there are a few people it would help. That said,
the help is minor and the worries about a slippery slope to voting aren't utterly
trivial. So a small thing that helps people now vs. a very unlikely thing (but not
impossible) that might hurt the culture down the road? I'm gently leaning toward
the short-term gains being worth the improbable long-term risk. Hobit (talk) 04:32,
2 January 2021 (UTC)
Oppose per Johnuniq ~ HAL333 04:45, 2 January 2021 (UTC)
weak Support If we can have {{Agree}} and {{Disagree}} why not Support or Oppose?
RudolfRed (talk) 05:03, 2 January 2021 (UTC)
Like this: {{agree|1=Support}} → Support . Now, how to lose the gaudy green tick?
--SmokeyJoe (talk) 06:55, 2 January 2021 (UTC)
{{strong}}? {{strong|Support}} → Support. --SmokeyJoe (talk) 07:06, 2 January 2021
(UTC)
Does it substitute? {{subst:strong|Support}} → Support. --SmokeyJoe (talk) 07:46, 2
January 2021 (UTC)
<strong {{#if:|role="{{{role}}}"}} {{#if:|class="{{{class}}}"}} {{#if:|
id="{{{id}}}"}} {{#if:|style="{{{style}}}"}} {{#if:|
title="{{{title}}}"}}>Support</strong>. Oh dear, that's a mess of wikimarkup, isn't
it. --SmokeyJoe (talk) 07:48, 2 January 2021 (UTC)
Usually I eschew starting my comment with a bolded word, precisely to place
emphasis on discussion over voting. Assuming the community is truly dedicated to
making decisions through discussion, I do not favour having templates that give
more prominence to votes. isaacl (talk) 07:18, 2 January 2021 (UTC)
@Isaacl: the opposite is that there are so many words in a section that prefacing
the section with a bold helps you know what to expect, especially in confusingly
worded arguments you know better what they're trying to get at. eg when closing
RfCs I don't necessarily close based on vote, but knowing a binary yes/no before a
comment helps follow the comment and get a general feel of where the discussion
lies. ProcrastinatingReader (talk) 19:20, 2 January 2021 (UTC)
I wrote something similar once about how knowing where an argument is heading can
help provide context and thus improve understanding. Nonetheless, it can be done
with a thesis sentence, rather than a single bolded word. I appreciate many people
like starting with a single bolded word. I believe, though, that it puts more
emphasis on voting and tabulation of votes versus discussion. isaacl (talk) 19:28,
2 January 2021 (UTC)
I'll support such templates, not because I'd use them myself, but I see no
justification for preventing other people from using them. When instructions are
given for how to participate in XFD discussions, a summary word in bold is
suggested.[2][3][4][5][6] On the rare occasions when I take part in such
discussions on other wikis I have to go round searching other people's comments for
the appropriate syntax so I can sympathise with the difficulties of occasional !
voters here. Thincat (talk) 09:48, 2 January 2021 (UTC)
Oppose. This is a good example of the failure to understand the cost of complexity
in terms of barrier to entry. Multiple ways to accomplish the same thing is
unnecessary complexity, unjustified by the perceived need to let every editor "have
it their way" (apparently because they are unpaid). Anyway, the template syntax is
no less prone to typing error than the markup. In the worst case the editor can
omit the bolding and it may be fixed by another editor per TPO. To the extent that
is not done, a few very rare cases of unbolded !votes are not a significant
problem. ―Mandruss ☎ 11:29, 2 January 2021 (UTC)
OPPOSE - The goal is simply to highlight what your opinion is. There are lots of
ways to do this. As demonstrated here, ALL-CAPS works too. Blueboar (talk) 14:16, 2
January 2021 (UTC)
To disincentivise plain voting, we could adopt these templates, but ensure they
only output an empty string :) – Uanfala (talk) 16:56, 2 January 2021 (UTC)
Oppose This is NOT a problem. No SOLUTION is necessary. GenQuest "scribble" 22:02,
2 January 2021 (UTC)
Oppose - per User:GenQuest and User:Mandruss (and probably a few others that I
agree with for other points). Or, if you wish for greater detail, why would we
decrease inconsistency between multiple projects by increasing inconsistency in one
project? Having the same method for producing bold "oppose" and "support" as is
used for making other things bold throughout Wikipedia is beneficial to the general
run of users on Wikipedia.--Khajidha (talk) 00:33, 3 January 2021 (UTC)
Support. Minimal implementation cost, minimal burden on other users, and well-
defined use case. Thincat put it well. I understand the instinctual "no voting
templates!" response, but there's no icon and no emphasis on the opinion. It would
be a good idea to brainstorm ways to enforce current community norms around !voting
if these templates are created, though. Enterprisey (talk!) 00:52, 3 January 2021
(UTC)
Sure. If there are no icons, {{Support}} and {{Oppose}} become shortcuts for wiki
markup. As with SmokeyJoe I use an iPad to edit Wikipedia, and typing {{Support}}
would be slightly better for me than '''Support'''. I also agree on what Thincat
and Enterprisey said. GMX (on the go) 16:00, 3 January 2021 (UTC)
{{Support}} The cognitive dissonance of people typing '''Oppose''' in this
discussion is remarkable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits
16:19, 3 January 2021 (UTC)
As one of the several people who have explained why a template producing the same
output as '''Oppose''' is not desirable I find this ad hominem to be in rather bad
taste. Thryduulf (talk) 20:40, 3 January 2021 (UTC)
@Thryduulf: Andy has a point here about how people comment regardless of the
existence of the template, it's not an ad hominem. Thanks. Mike Peel (talk) 21:07,
3 January 2021 (UTC)
Effectively calling everyone idiots, without explaining why they're being called
idiots, sort of looks like an ad hominem, doesn't it? – Uanfala (talk) 21:45, 3
January 2021 (UTC)
@Mike Peel: if Andy has a point other than insulting the intelligence of people
with a different opinion on these templates to him then I am at a loss as to what
it is. I can't prove it, obviously, but the impression I get is that he has read
only the bolded words (which would be rather ironic for this discussion). Thryduulf
(talk) 23:57, 3 January 2021 (UTC)
Competent editors can see that Andy's comment was 100% insult and 0% argument, and
therefore a "not-not-vote" of no consequence. A competent closer, if there is a
closer, would simply discard it. ―Mandruss ☎ 16:10, 4 January 2021 (UTC)
weak support I would not use it, but why not have such a template if it makes it
easier for some? Graeme Bartlett (talk) 02:52, 4 January 2021 (UTC)
Oppose. Tends to encourage voting rather than discussion aimed at generating a
consensus. Solution looking for a problem. Stifle (talk) 09:56, 4 January 2021
(UTC)
OPPOSE per Thryduulf, isaacl and Stifle. Those who can't write bold should use the
workarounds mentioned above, address their shortcomings (which would help in a far
wider range of applicability) or simply write all caps, as Blueboar suggested. ◅
Sebastian 11:17, 4 January 2021 (UTC)
Oppose per Johnuniq, Mandruss and GenQuest - This really is a solution looking for
a problem. I appreciate Commons etc use {{Support}} however we're not Commons,
Every project has their own way of doings things and "'''Support'''" is our way of
doing things. Personally I use "'''Support'''" on all projects as it's what I'm
used too (unless it looks out of place which I then change it after (ie with RFAs
etc)). –Davey2010Talk 11:30, 4 January 2021 (UTC)
Support: trivial implementation, no disruption of previous practices, no migration
cost, aligns well with other Wikimedia projects, probably slightly less chance of
unbalanced markers (e.g. 2x2 vs 3x3). --MarioGom (talk) 14:06, 4 January 2021 (UTC)
As much as I myself mostly start comments with a bold oppose text, I don't think
this a template necessary. Firstly, per there being a wide range of commonly used !
vote strings and having a template for each is a massive overkill. Will we be
needing {{Option|2}} for Option 2 or something? This proposal fails to list (even
as example) the actual templates, there are surely more than the two mentioned. And
having only a few of these will just create extra differences in markup. I would
want to see some statistics of the commonly bolded terms in discussion first.
Furthermore, the non-existent complexity of the output does not warrant a template,
it is unnecessarily convoluting what is a simple text message, nor is having (even
more) templates in text helpful when it's literally default bold syntax. Then
there's grammar -- what if I want it lowercase or add other words that need
bolding? These just feel like ballot checkboxes rather than a summary of the
opinion to follow. Finally, pretty sure this will just make using visual editor way
more complicated needing to insert a template when one could have clicked/tapped
bold like is standard in every other text editor. — HELLKNOWZ ▎TALK 14:39, 4
January 2021 (UTC)
This is a good point - the common recommendations at current discussions are:
"allow recreation", "containerize"/"containerise", "convert to an article"/"write
an article", "delete", "disambiguate", "draftify", "dual merge", "endorse", "keep",
"listfy", "merge", "move", "oppose", "overturn", "purge", "redirect", "refine",
"relist", "rename", "rename", "restore", "retarget", "reverse merge", "revert",
"setindexify", "soft redirect", "split", "subst", "support", "upmerge", "userfy",
"wrap"/"wrapperify" and "wrong venue". Then you have modifiers like "all", "don't",
"for now", "in principle", "leaning", "speedy", "strong", "weak" and "without
prejudice" and non-recommendation bolds like "comment", "note", "question" and
"update". Covering all these would need between 40 and 50 templates. Thryduulf
(talk) 13:09, 5 January 2021 (UTC)
@Thryduulf: We're only talking about the most common uses of such templates, which
are also used on other wikis, like those mentioned in the proposal. There's a latin
phrase you could use to explain your comment if you want, though. Thanks. Mike Peel
(talk) 22:04, 5 January 2021 (UTC)
These are the the recommendations used multiple times in a current discussion
and/or in multiple current discussions on en.wp (AfD, RfD, CfD, TfD, MfD, DRV, MRV
and RM; although there were none exclusive to MfD). To be useful to editors at
en.wp they will need to cover the !votes they will commonly make otherwise they
will frequently have to use the standard ''' markup which negates the whole point
of having templates in the first place. What other wikis do is not relevant to
discussions on the English Wikipedia. Thryduulf (talk) 00:43, 6 January 2021 (UTC)
Why not I would never use them, but that doesn't mean that others wouldn't find
them useful. Most of the oppose votes are people who have no personal use for them.
Why is this even a vote? The OP could have saved themselves some trouble by just
creating them. I am struggling to figure out why we needed to even have this
discussion/vote. --Jayron32 15:43, 4 January 2021 (UTC)
No trouble would have been saved by doing that, because (a) the templates are
salted and (b) I would have tagged than as {{db-g4}} if I had noticed them being
recreated. We would have ended up here anyway after a few more rounds of
bureaucracy. * Pppery * it has begun... 15:47, 4 January 2021 (UTC)
It's quite apparent that this is controversial. Sure, people often slip in new
templates that would be controversial if discussed beforehand, but I don't consider
that good faith practice. Editors are less likely to challenge by WP:TFD because
it's such a hassle (and, for some, because they aren't aware of TfD or don't have
the time to learn how to use it correctly). If the creation of a template were as
easily challenged as an ordinary edit, standard BRD process would work fine, but
that is unfortunately not the case. I commend the proposer for "discussing first"
in this case, despite the fact that it likely would have been easier to get
forgiveness than permission. ―Mandruss ☎ 16:38, 4 January 2021 (UTC)
My primary concern is that templates (in general) too often shift from being
“optional” to being “preferred” ... and then to “expected” and finally to
essentially “mandatory”. I know this is not the intent here, but I have seen this
shift occur too many times with other templates to be comfortable with it now.
Blueboar (talk) 17:03, 4 January 2021 (UTC)
@Blueboar: Definitely not the intent here. I can't say that this won't happen, but
if it does, then presumably it would be accompanied by discussions that you and
others (including myself) could object to. Thanks. Mike Peel (talk) 21:58, 5
January 2021 (UTC)
My experience with “template creep” is that there often isn’t any discussion in
which to state an objection. So I am objecting NOW, while I have a chance to do so.
Blueboar (talk) 22:25, 5 January 2021 (UTC)
Orz... can we have "Strong Meh" as well? But really we already have
Template:Done/See_also and we also don't have a problem with people actually typing
"Support" so I really don't care if a template does it as well, however I don't
want to see a proliferation of media like File:Symbol confirmed.svg on every
discussion, less concerned if it is stylized text (even check marks that are not
image files). — xaosflux Talk 17:22, 4 January 2021 (UTC)
Sadly {{meh}} already exists as Face-plain.svg. We would probably want {{weak meh}}
as well — GhostInTheMachine talk to me 10:17, 6 January 2021 (UTC)
Even without images, we can still run into problems with a page's transclusion
limit which could end up breaking the village pumps or ANI where there are lots of
proposals with lots of bolded !votes. Not worth the trouble just to save two
keystrokes. I'm also worried about what Blueboar points out with templates going
from "optional"->"preferred"->"required" over time. In this case, it would threaten
to undermine the already weak "discussion-not-vote" consensus process which worries
me per WP:NOTAVOTE and meatball:VotingIsEvil. — Wug·a·po·des 22:20, 4 January 2021
(UTC)
We could always have a bot auto-subst them (although it would clutter the page
history). Enterprisey (talk!) 08:54, 5 January 2021 (UTC)
@Enterprisey: I suggested that in the proposal. I could code up a bot to do so if
needed. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
I left it vague, but to be clear, I think that's a worse idea for precisely the
reason Enterprisey hints at. The last thing I want is a WP:COSMETICBOT roaming
around making non-visible changes to markup and cluttering discussion diffs just to
help powerusers save 2 keystrokes. It would probably also make people think they
themselves ought to be substituting it which actually costs them 4 keystrokes
compared to just using bare markup. — Wug·a·po·des 02:23, 6 January 2021 (UTC)
Support without the icon and with substitution to avoid transclusion limit. As
other projects have implemented it, I have found myself trying the template before
realize that here doesn't work. Alexcalamaro (talk) 23:59, 4 January 2021 (UTC)
O - or a bold S is simple enough or better yet, separate the sections like we do at
RfA. Atsme 💬 📧 15:30, 5 January 2021 (UTC)
@Atsme: Great, let's support more options for commenting, like this proposed
template? Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
Oppose: or alternatively doing it properly, Hell no. I despise bolded words as a
substitute to discussion and the lack of nuance of just going support or oppose is
not to be encouraged. Spartaz Humbug! 19:58, 5 January 2021 (UTC)
@Spartaz: But you just used bold words in your comment? This proposal is for a
convenience template to make it easier for other editors to comment, not a
substitute. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
Oppose. The convenience factor does not outweigh the barrier to newcomer
participation created by use of excessive templates in simple discussions.
--SmokeyJoe (talk) 00:19, 7 January 2021 (UTC)
Support I support anyone making and using almost any template, and the creation of
templates rarely requires a vote or discussion. I must be misunderstanding
something here. As noted above, we already have {{agree}} and {{meh}} which are
similar templates that people can use or ignore. Why the opposition? No one is
proposing to force or require the use of this template, so most people would either
not know it exists or not care. Other Wikimedia projects like Commons use these
templates, so it is understandable to me that if some people want to use it, then
they might look for it across projects. In 2005 the template was deleted for use of
images, but no one is proposing that right now. To a typical reader they would not
know a template is being used at all.
I think the point of this discussion is that this template has been deleted ~10
times since 2005 because of prior use of images, but I see no harm or cost in
having the template available for those who want to use it now. Blue Rasberry
(talk) 16:25, 7 January 2021 (UTC)
{{weak strongest possible oppose}} Majavah (talk!) 18:51, 7 January 2021 (UTC)
Oppose: (1) It's not that hard to type the non-templated equivalent (2) It
encourages !voting without !vote rationale, (3) It only increases the number of
templates transcluded on discussion pages. Thanks! Plastikspork ―Œ(talk) 20:03, 7
January 2021 (UTC)
@Plastikspork, you don't ever edit from a smartphone, right? We have editors above
who say that it actually is "that hard" for them to type straight apostrophes (').
I think we can trust them that they struggle with this. WhatamIdoing (talk) 23:21,
8 January 2021 (UTC)
Then type in all caps (as suggested above), which is even easier than finding the
{} symbols. Thanks! Plastikspork ―Œ(talk) 23:30, 8 January 2021 (UTC)
That's a good point. On my bog-standard Android keyboard ' is on the first page of
symbols, { and } are on the second page. Additionally, when editing using the
Wikipedia Android app there is a single button that automatically inserts the
markup for bold text, there is no equivalent for templates. Unless iOS works very
differently (I own no Apple products so can't check) then it seems very likely that
templates being easier to insert than bold markup for smartphone users looks
fallacious. Thryduulf (talk) 14:01, 9 January 2021 (UTC)
@Thryduulf: Checking on an iphone (in a text application not in a Wikipedia app), '
is on the first page and { is on the second, but if I enter ' then the characters
go back to the alphabet, while if I enter { then it stays on the second page, so
it's easier to add a second {. Does android behave the same? Thanks. Mike Peel
(talk) 17:31, 9 January 2021 (UTC)
I just tried editing in the Wikipedia app on iPhone, and I see the same keyboard
behavior there. Thanks. Mike Peel (talk) 17:33, 9 January 2021 (UTC)
If there is a consensus to try to make it easier to enter bold or italic text
without using a straight single quote, then I'd prefer it be done in a generic way
for all text, not just specific words. Let's extend wikitext markup in some way,
for example. Maybe something like @‘’’, @’’’, and other combinations of
typographical quotes can be supported. isaacl (talk) 17:01, 9 January 2021 (UTC)
Allow linking to the "submitted" draft article available for review
To avoid a WP:TALKFORK, please hold discussion at Wikipedia talk:Manual of
Style/Linking#Semi-protected edit request on 7 January 2021. (non-admin closure)
{{u|Sdkb}} talk 19:18, 7 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.
Wikipedia policy and guidelines should be solution-oriented and future-proof the
edits by being oriented towards "non-alpha" editors (IPs and occasional editors)
who contribute the majority of the content, hence they are the core and most
important editors/stakeholders. Whereas policies and guidelines are designed by the
and for the alpha editors who love to argue, waste time in pedantic debates,
nitpick on minor thing to turn mole into hills, big turn off for the "core
contributors" (IPs and occasional editors) of the wikipedia, who gets disgusted and
walk away.

Please amend the MOS:DRAFTNOLINK guideline in such a way that it must permit the
linking of draft articles that have been submitted for the review. You can still
impose restriction on linking the sandbox articles or the draft articles that have
not been submitted for the review. You can read the benefits and arguments in favor
of this proposed edit here and more detailed benefits and concerns here. I was
redirected to MOS:LINKING here and to VPR, what a wild goose chase, down the people
in time-wasting stuff. Please note that the similar concerns have been already
documented by numerous other editors Wikipedia:Why Wikipedia is not so great, my
proposed edit mitigates some of those concerns. To start with, just allow linking
to the submitted drafts as requested here. I will not be monitoring this talkpage
here, I have also stopped monitoring talkpages where I had submitted my proposals
to edit MOS guidelines. I have already wasted too much time on this bureaucratic
hurdle/issues. I leave it to the other members of the community here to tke this to
some logical conclusion. Big thank you to you all for your patience to volunteer
your time here to help others. 58.182.176.169 (talk) 15:43, 7 January 2021 (UTC)

You can link to the article without the Draft: prefix. Once the draft is accepted,
the red link will become blue. Allowing links to the draft space from the main
space would aggravate our problem with spammers and undisclosed paid editors.
MarioGom (talk) 18:22, 7 January 2021 (UTC)
Further discussion should happen at the linked-to discussion, Wikipedia talk:Manual
of Style/Layout § Semi-protected edit request on 7 January 2021.
davidwr/(talk)/(contribs) 18:35, 7 January 2021 (UTC)
Do you mean Wikipedia talk:Manual of Style/Linking#Semi-protected edit request on 7
January 2021? — HELLKNOWZ ▎TALK 18:47, 7 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.
Bring back Superprotect protection
I believe this would help the wiki a lot. It wasn't completely useless. I feel like
all pages with Wikipedia:(Article Name) need it to prevent vandalism. Of course not
pages that contain user-generated content such as the Village Pump section.

This is really just a suggestion. SoyokoAnis (talk) 04:01, 8 January 2021 (UTC)

Unless you are implying administrators are vandals (which is clearly not the case),
then superprotect is irrelevant here. * Pppery * it has begun... 04:03, 8 January
2021 (UTC)
Superprotection was a WMF-implemented feature that allowed staff to prevent even
administrators from editing certain pages. Are you sure this is the feature you are
referring to? – Teratix ₵ 10:21, 8 January 2021 (UTC)
Oh, no. Administrators aren't vandals I just feel like those pages shouldn't be
edited by anyone except Wikimedia Staff. Yes, that is the feature I was referring
to. SoyokoAnis User Page 22:12, 8 January 2021 (UTC)
Why? This is a wiki, after all. * Pppery * it has begun... 22:17, 8 January 2021
(UTC)
@SoyokoAnis: The Foundation pretty much leaves it to the "local Wiki editors" for
things that don't involve multiple projects or things external to the project, like
legal issues. What you are asking would represent a huge philosophical shift. The
only time I can see it being used would be for OFFICE actions and possibly for
policies with legal implications, but it's not needed there because we can trust
administrators to not do anything that goes against an OFFICE edict. Besides, the
WMF has enough work to do, they don't need to be wasting time monitoring
{{protected edit}} requests on local Wikis. Oh, I can think of one place where this
would come in handy: If a court ordered the foundation to prevent administrators
from editing a page. But I don't see that happening. davidwr/(talk)/(contribs)
22:19, 8 January 2021 (UTC)
Given that it's not the WMF's job to participate in content disputes unless there
are legal reasons to do so, can you show an example where superprotect could have
been useful if it was available? Majavah (talk!) 23:06, 8 January 2021 (UTC)
@SoyokoAnis, I think you are looking for WP:FULL protection, which already exists.
WhatamIdoing (talk) 23:26, 8 January 2021 (UTC)
Blocking Request for User:IN
Hey admins, User:IN is continuously doing useless edits, against WP:NOTHERE policy.
I think a blocking request is needed. He/She was doing the same thing like this in
Chinese Wikipedia and is in blocking status now. -- BrandNew Jim Zhang (talk)
14:44, 8 January 2021 (UTC)

Examples? --Golbez (talk) 15:55, 8 January 2021 (UTC)

Categories: Wikipedia village pumpWikipedia proposalsWikipedia requests for comment
Navigation menu
Not logged in
Talk
Contributions
Create account
Log in
Project pageTalk
ReadEditNew sectionView historySearch
Search Wikipedia
Main page
Contents
Current events
Random article
About Wikipedia
Contact us
Donate
Contribute
Help
Learn to edit
Community portal
Recent changes
Upload file
Tools
What links here
Related changes
Special pages
Permanent link
Page information
Wikidata item
Print/export
Download as PDF
Printable version
In other projects
Wikimedia Commons
Wikibooks
Wikinews

Languages
‫العربية‬
Deutsch
Español
Bahasa Indonesia
Jawa
Bahasa Melayu
Português
Русский
‫اردو‬
35 more
Edit links
This page was last edited on 9 January 2021, at 20:24 (UTC).
Text is available under the Creative Commons Attribution-ShareAlike License;
additional terms may apply. By using this site, you agree to the Terms of Use and
Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation,
Inc., a non-profit organization.
Privacy policyAbout WikipediaDisclaimersContact WikipediaMobile
viewDevelopersStatisticsCookie statementWikimedia FoundationPowered by MediaWiki