Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 122.62.77.220 (talk) at 21:33, 29 December 2020 (→‎Wiki App Idea: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New proposals are discussed here. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


Succession boxes for US Presidents

Following on from the discussion started here:

Talk:Donald Trump#What happened to the succession boxes?

How does the community feel about succession boxes and their inclusion in the articles about US Presidents specifically? The following three options were presented on the talk page above:

  1. The succession boxes should be included in all U.S. presidents' BLPs.
  2. The succession boxes should be omitted from all U.S. presidents' BLPs.
  3. One size does not fit all. Cross-article consistency is less important than flexibility. Decide on a case-by-case basis at article level.

06:39, 13 November 2020 (UTC)

  • 2 - The information therein is somewhat redundant with the Preceded by and Succeeded by fields of {{Infobox officeholder}}, while far less visible and accessible being at the bottom of the article. What little anecdotal evidence we have (from editors who used to be only readers) suggests that readers rarely or never use the succession boxes. At Donald Trump, the boxes were removed after brief discussion in December 2018, and the only arguments in opposition to that have been that U.S. presidents' BLPs must be consistent. No one has even attempted to make the case that the boxes actually benefit readers enough to justify the space required, and I feel that would be a very difficult case to make. Ok, so let's make U.S. presidents' BLPs consistent. ―Mandruss ☎ 09:26, 1 September 2020 (UTC)[reply]
  • 2 - succession boxes are such an outdated navigation tool on en.wiki. We have as Mandruss pointed above, the relevant fields in the infobox, but also navigation templates such as {{US Presidents}} which already show the entire list. Succession boxes just add clutter as they are much more larger and offer no additional value. --Gonnym (talk) 10:28, 1 September 2020 (UTC)[reply]
  • 1 or 2 - but this should include all the US presidential & vice presidential nominees bios. GoodDay (talk) 14:16, 1 September 2020 (UTC)[reply]
  • 2 seem pretty redundant/useless now. We show the same information in better ways in articles. Showing succession for the Nobel Peace Prize (ref Obama) is not helpful. Succession for major office posts is already shown in infobox. I support broader removal from all such articles. Also noting that cobaltcigs's mockup below is a significant improvement, and in any case the boxes should be updated to that if kept. ProcrastinatingReader (talk) 13:50, 6 September 2020 (UTC)[reply]
  • 2 I think succession boxes in general have had their day. The infobox is much more useful, because it puts the short summary of the individaul write at the top of the article. If an individaul has a lot of offices that wouldd make the infobox too long, it's always possible to put some of the offices in a collapsed format, as is done with the infobox for John A. Macdonald. --Mr Serjeant Buzfuz (talk) 17:32, 7 September 2020 (UTC)[reply]
  • 1 – Succession boxes remain useful for cases where the inclusion of an office in the infobox of a given article wouldn't meet MOS:INFOBOXPURPOSE. For example, in the Canadian context, it's not uncommon for there to be "secondary" ministerial titles that are typically held alongside a more significant portfolio, such as Minister responsible for La Francophonie. Despite being a significant office, it simply wouldn't be important enough to include in the infobox in most cases. 207.161.86.162 (talk) 05:38, 15 September 2020 (UTC)[reply]
  • 1 Not sure where you're getting "anecdotal evidence" from. I use them all the time for navigation. Perhaps among the most useful things on a page, particularly if a person has held multiple offices or secondary titles over their lifetime. The infobox at the top is not always the clearest nor complete, and sometimes troublesome to scroll all the way back up there if you're already at the bottom. Walrasiad (talk) 07:41, 17 September 2020 (UTC)[reply]
  • 1 I've found them very useful for navigating articles. PaleAqua (talk) 18:08, 5 October 2020 (UTC)[reply]
  • 1 MOS:INFOBOXPURPOSE is fundamentally at odds with relying on infoboxes to be a complete record of succession in offices. In the case of Trump, there's no real conflict; he's held one major political office, and it's the most relevant thing in his career, so it goes in the infobox. That's not the case for many political figures; in the UK, chronicling someone's ascent through a series of junior ministerial posts might require bloating the infobox to an enormous extent at the expense of highlighting what's most important. (Winston Churchill is an excellent example of why collapsible infoboxes don't solve this: it's impossible from the current arrangement to infer which offices besides PM were most salient to his career, probably Chancellor and Admiralty.) The more visible your navigation element, the more judicious you need to be about what you put in it; succession boxes have always been at the bottom of the article so that they can be more complete than infoboxes without getting in the way of a quick skim. If we're going to delete anything, it should be cruft like {{US Presidents}}. Salience is built into succession boxes: the actions, policies, and careers of an individual's predecessor and successor are necessarily of greater relevance than most or all of those further removed. (Or to put it more simply, it's logical to want to navigate from Obama to GW Bush or to Trump; there's no real case for wanting a "convenient" mechanism to jump from Obama to Tyler or Benjamin Harrison or Buchanan.) The idea that showing the "entire list" adds "more value" is the same fallacy you see in amateur GUI design, where jamming more buttons into the toolbar or more options onto the menu is uncritically regarded as an improvement. I do agree that there are some things crammed into succession boxes that don't fit the model of a single office more or less continuously occupied by different people—I would fully support removal of Nobel Prize succession, as ProcrastinatingReader suggests. Anecdotally, I've put a certain amount of time into installing succession boxes over the years because I *do* find them useful as a reader—this was something I wanted even as a kid reading paper encyclopedias! I find scanning through tiny, irregularly-laid-out text in big infoboxes less easy to navigate than dropping to the bottom of the article and consulting a succession box. Choess (talk) 14:45, 13 November 2020 (UTC)[reply]
  • 1 Succession boxes have a function. The information in the succession boxes should not be moved to the infobox, which serves a different purpose with minor overlap (MOS:INFOBOXPURPOSE). The formatting of the succession boxes might be improved. Johannes Schade (talk) 10:01, 14 November 2020 (UTC)[reply]
  • 2 Never seen the point of succession boxes, and they often duplicate footer templates that are more effective navigation tools (in this example, {{US Presidents}} which includes the dates of office for each president). Number 57 12:26, 21 November 2020 (UTC)[reply]
    Winston Churchill is a mobile view scrolling accessibility nightmare.... it has been used as an example of what not to do by thoses who oppose any infobox. --Moxy 🍁 14:47, 21 November 2020 (UTC)[reply]
    Regarding the issue of duplication, what about the case of offices that don't and shouldn't have navboxes (like "secondary" ministerial titles such as the Canadian Minister responsible for Official Languages, as I mentioned above)? 207.161.86.162 (talk) 01:51, 22 November 2020 (UTC)[reply]
  • 1 -- Succession boxes fulfil a useful function in facilitating navigation between successive holders of the same office. They appear near the end of an article, which should avoid them causing difficulty for mobile users. The mistake is having the same information repeated in infoboxes. The inclusion there of predecessor, successor, superior (monarch, government, etc.) seems unnecessary in a place intended to provide a brief outline: office held and dates should be enough there. Those who want more than then refer to the succession box. Peterkingiron (talk) 16:47, 22 November 2020 (UTC)[reply]
  • 1. Navigation features become confusing when they are not consistent across a set. Option 3 is kind of boneheaded; there is no US President for whom succession information is irrelevant (or even less relevant than for any others), so the "flexibility" argument simply makes no sense. I think someone just copied it wholesale from arguments about infoboxes, which are a very different kind of template.  — SMcCandlish ☏ ¢ 😼  03:54, 8 December 2020 (UTC)[reply]
  • 1 -- Such boxes seem somewhat more detailed than the ones at the top of the article.73.110.217.186 (talk) 04:39, 8 December 2020 (UTC)[reply]
  • 2 - The boxes are redundant with similar links in the infobox and in the footer of the navbox. We don't need the same thing in the article 3 times! Kaldari (talk) 15:09, 8 December 2020 (UTC)[reply]
  • 2 ProcrastinatingReader makes the most sense. Agree 100% with his sentiments. GenQuest "scribble" 14:24, 17 December 2020 (UTC)[reply]

Flatten your succession boxes and/or abs

So I've suggested this before but here is my initial visual mock-up. What we know today as "succession boxes" should be flattened out to look roughly like this:

Ideally the template would also read each row's data (names, order, dates, annotations, whatever) by looking up {{PAGENAME}} on centralized lists (titled e.g. Module:Succession/President of the United States) and format the lookup results accordingly. So the calling syntax might be reduced to something like this (with various shorthand abbreviations allowed): 

{{succession navbox|Illinois Senate|United States Senate|President of the United States}}

Unrecognized positions such as Community Organizer (Chicago) would be ignored and impossible for noobs to casually add. Such a system would greatly reduce screen waste, allow tighter control over accuracy, and protect against the random crap that existing succession boxes universally attract. I could probably create it within a few days, if there is interest. ―cobaltcigs 12:11, 1 September 2020 (UTC)[reply]

Considering that the existing boxes are collapsed, I don't think this is really relevant to this discussion (and it feels like a bit of a distracting hijack, to be honest). From what I've seen, the arguments against the boxes are not that they occupy too much screen real estate when temporarily expanded by a reader. There is no reason to believe that this would be more needed or used than the existing boxes. ―Mandruss ☎ 12:38, 1 September 2020 (UTC) (Strike after subsequent discussion.) ―Mandruss ☎ 13:35, 1 September 2020 (UTC)[reply]
Perhaps User:Gonnym would clarify Succession boxes just add clutter as they are much more larger in light of the fact that they are collapsed, but my reference to the space required was about other types of space: File size, post-expand include size, space in the edit window, and even the screen space required for the collapse bar. If the boxes are rarely used, even those relatively minor things are unjustified. Massive unnecessary clutter is usually a gradual accumulation of relatively minor things just like this – "hey, one more collapse bar won't hurt" – and we can only address them one at a time. ―Mandruss ☎ 13:03, 1 September 2020 (UTC)[reply]
A template shouldn't be huge even when expended if it doesn't need to. Compare the size of the succession section (Offices and distinctions) to Template:Barack Obama. Look at how much link data the navbox has compared to the succession one and yet the succession one is much larger and duplicates information presented elsewhere in the article, including right next to it with {{US Presidents}}. --Gonnym (talk) 13:17, 1 September 2020 (UTC)[reply]
@Gonnym: In that case, cobaltcigs's proposal would appear to address at least some of your concerns. Would you support it as a solution, then? ―Mandruss ☎ 13:23, 1 September 2020 (UTC)[reply]
No, not really. It is better than the current succession templates, but it's still not needed as it's still duplicating data right next to it. Using the above example, it's duplicating {{US Presidents}} and {{United States senators from Illinois}} with the 13th District seat seemingly not being important enough to warrant a navigation template. And again, all 3 are the first pieces of information right after his image in the infobox. --Gonnym (talk) 13:30, 1 September 2020 (UTC)[reply]
Fair enough - I am still learning the ropes here. ScottishNardualElf (talk) 22:25, 1 September 2020 (UTC)[reply]
@ScottishNardualElf: You might get more attention on this topic, if you make this discussion an RFC. GoodDay (talk) 15:33, 3 September 2020 (UTC)[reply]

So this proposal was actually intended as a compromise between the status quo and my (unpopular, I thought) personal opinion that totally getting rid of succession boxes would be better. Support for the latter seems higher than predicted, which is good. As long as we whack the {{portal bar}}s next. ―cobaltcigs 22:18, 10 September 2020 (UTC)[reply]

@Cobaltcigs: If you support option 2, feel free to indicate same in the preceding section, for clarity. ―Mandruss ☎ 15:14, 11 September 2020 (UTC)[reply]
  • I think the idea of flattenning the boxes is the best idea--and possibly not just for US presidents but in general. They're a rather primitive visual element, reminiscent of the earliest years of html. The basic information they give is useful--the prominence in the appearance of the article dadds nothing to that. DGG ( talk ) 00:55, 19 September 2020 (UTC)[reply]
  • Broadly support flattening but the sample doesn't work well without some kind of separator in a wide window (and particularly as the number of offices rises). If the middle column could be made relatively narrow, and the left and right columns were right and left aligned respectively it would keep things visually connected ~Hydronium~Hydroxide~(Talk)~ 02:28, 19 September 2020 (UTC)[reply]
I would like to see how, using such a list, you could handle the succession box for Grover Cleveland. 109.186.211.111 (talk) 01:13, 16 November 2020 (UTC)[reply]
Cleveland's political career is not especially complex, I assume it would go Sheriff of Erie County → Mayor of Buffalo → Governor of New York → President of the United States → President of the United States (Keeping his two terms as President separate.) Even for someone like Henry Clay, who bounced between the House and Senate with astonishing frequency, would be fairly simple, if not rather long.
  • No objection -- I approach this issue from the point of view of UK, where there are successions other than of offices held. Someone who had a long and varied career may indeed have a long succession box, but a shorter format would be acceptable, if this change can be made by some automatic means. However the issue is complicated by the existence of a "with" field, which applies to UK MPs before 1832 and to US senators (since each state elects 2).
  • Agreed. The current boxes take up too much space, for no good reason. Thanks for the demo, cobaltcigs.  — SMcCandlish ☏ ¢ 😼  03:51, 8 December 2020 (UTC)[reply]
  • Comment - It may make sense to add a 4th column for those date ranges. It could be in the same place it is now. Just that having a column would align the dates nicely. –Novem Linguae (talk) 04:41, 8 December 2020 (UTC)[reply]
  • Good idea - If we're going to keep succession boxes, this is a much better format for them. Kaldari (talk) 15:14, 8 December 2020 (UTC)[reply]
  • Support - These boxes take up space and I like the alternative format. If there is a format we can adopt here and there, I'd do it. I see an analogous thing when big boxes are inserted with lists of formally important people, like this one. I squeeze those down when I can so they take less vertical space. Good thought, user:cobaltcigs. -- econterms (talk) 02:32, 13 December 2020 (UTC)[reply]
  • Support displaying similar information using less space. We could even move the preceded/succeeded by headers into the top band beside the "Offices of Joe Schmoe" title. Certes (talk) 12:57, 13 December 2020 (UTC)[reply]

Expansion of scope: succession boxes

This question should be expanded to include all the US presidential & vice presidential candidate bios. GoodDay (talk) 14:13, 1 September 2020 (UTC)[reply]

Sure, but why stop there? What about use of the same boxes in the BLPs for other U.S. officeholders? What about non-U.S. officeholders? If you're expanding scope at all, the only logical place to stop expanding would be to include all uses of the boxes anywhere in the encyclopedia. That's a far larger question, and before you know it you have a months-long discussion, very possibly all wasted time due to a no-consensus outcome. I say we can take this on in smaller pieces without undue harm to the encyclopedia, but any consensus here would be a factor in future discussions about other pieces. If we reach a consensus for option 1, there probably won't be any future discussions anyway. ―Mandruss ☎ 14:44, 1 September 2020 (UTC)[reply]
It wasn't my decision to delete the succession boxes at Donald Trump, thus putting that article out-of-sync with the others. GoodDay (talk) 15:38, 1 September 2020 (UTC)[reply]
That again??! You're right, it wasn't your decision. It was a local consensus not precluded by a community consensus, as explained to you more than once. The cross-article consistency factor was argued, and it was not enough to sway consensus toward keep. Please cease making me keep explaining to you how Wikipedia works, you have been around far too long for that. You are becoming disruptive. ―Mandruss ☎ 15:49, 1 September 2020 (UTC)[reply]
I'm not interested in getting into personal insults with you, so let's not go down that path. GoodDay (talk) 16:13, 1 September 2020 (UTC)[reply]
  • I think candidates and certainly spouses should not have succ-boxes. In any event, failed political candidates are generally NN, unless for other reasons. Presidential candidates usually hold some other office (or have done) so that this does not apply to them. Peterkingiron (talk) 16:47, 22 November 2020 (UTC)[reply]

Presidential & Vice Presidential candidate spouses

Note: Presidential candidate & Vice Presidential candidate spouses should be deleted from such bios. GoodDay (talk) 17:46, 14 November 2020 (UTC)[reply]

Update - I've deleted as many of them, as I could find. GoodDay (talk) 19:08, 23 November 2020 (UTC)[reply]

Closure

We need an administrator to close this expired RFC. GoodDay (talk) 12:35, 19 December 2020 (UTC)[reply]

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)[reply]

  • I don't think this is necessary, and keep in mind would only change for users with the English interface language set (everyone else will still get the system default). — xaosflux Talk 18:29, 3 November 2020 (UTC)[reply]
  • Support per MOS:ENDASH. This seems like a pretty simple grammar fix (albeit with a huge scale), so I'm not sure it needs a giant discussion here, but I'm also not sure where else the discussion would've been hosted, so I can see why you brought it here. To speak to Xaosflux's point, this shouldn't be something that only applies to English, so if we can figure out how to apply it to all languages, that'd be even better. {{u|Sdkb}} talk 22:56, 3 November 2020 (UTC)[reply]
    Shouldn't the punctuation on each project conform to its own language and MOS? The MOS on enwiki would certainly indicate that an en dash, not a hyphen, should be used here, but an em dash or hyphen may be correct in other languages. A centralized discussion on Meta would be a good place to confirm that each project's tab punctuation adheres to its own MOS. Armadillopteryx 00:46, 4 November 2020 (UTC)[reply]
  • Meh for en.wiki; they're all just horizontal lines. 99% of users have never noticed, and of that 1%, 96% won't care. None of our business for all other wikis. I assume I'm misunderstanding Sdkb's comment; you aren't suggesting that the result of a discussion here should affect all other wikis? --Floquenbeam (talk) 23:29, 3 November 2020 (UTC)[reply]
    @Floquenbeam: From what Xaosflux said above, it seems that a fix might only apply to the English Wikipedia with the English language interface set, not all language interfaces. We control all language interfaces on English Wikipedia. As for other Wikipedias, it might be nice to standardize among those, but that discussion would probably have to be held somewhere on Meta. {{u|Sdkb}} talk 23:35, 3 November 2020 (UTC)[reply]
    It's very likely you know more than me about this. But "We control all language interfaces on English Wikipedia" doesn't sound right at all. I think I must be missing a subtlety or distinction or term of art? Anyway, it isn't important that I understand. As long as you're not saying we should make changes for, say, es.wiki or Commons too - which it looks like you're not saying - then we're good. --Floquenbeam (talk) 23:42, 3 November 2020 (UTC)[reply]
    In Special:Preferences you can set your language. If unset or set to a language that doesn't have a locally created MediaWiki page, there is a default MediaWiki page used. Killiondude (talk) 00:19, 4 November 2020 (UTC)[reply]
    MediaWiki has a framework to support translations into different languages in its own user interface messages, as described by Killiondude, which is what Sdkb is describing regarding having control over all language interfaces on English Wikipedia. It has been long recommended for users not to change their preferences to another language, though, as a lot (most? all?) of customized messages have not been translated (and as I recall, even specifying a country-specific English variant, like en-uk, will cause a fallback to the default message, thereby losing the customization). isaacl (talk) 00:36, 4 November 2020 (UTC)[reply]
    @Killiondude and Isaacl: actually it seems that if a custom message is set but not translated, the custom message is used. At least in the sidebar - go to https://en.wikipedia.org/wiki/Earth?uselang=de (an en.wp page but with the interface language set to German). The second item in the "contribute"/"Mitmachen" section is the custom English "Learn to edit" in both English and German interfaces rather than the default "Introduction" / "Einführung". Thryduulf (talk) 01:41, 4 November 2020 (UTC)[reply]
    You can see what impact changing the interface language would have by appending ?uselang=xx (where xx is the language code you want to use) to the URL (or &uselang=xx if the URL already contains a ?). For example go to https://en.wikipedia.org/wiki/Earth?uselang=de to see an English Wikipedia article with the interface language in German. The article text remains in English, but all the tabs, sidebar links, etc. are in German. Thryduulf (talk) 01:41, 4 November 2020 (UTC)[reply]
    It took you all more effort than it was probably worth, but I finally understand. Thanks everyone for the patient explanations, sorry everyone for being technologically incompetent, and sorry User:Sdkb for momentarily implying you might have been saying something crazy. --Floquenbeam (talk) 16:26, 4 November 2020 (UTC)[reply]
    No worries at all! {{u|Sdkb}} talk 19:31, 4 November 2020 (UTC)[reply]
  • Support this change on enwiki (and other English-language projects) per MOS:ENDASH; projects in other languages should make sure the dash (or hyphen) used conforms to their own MOS. Armadillopteryx 00:46, 4 November 2020 (UTC)[reply]
  •  Comment: previous relevant discussion: Wikipedia:Village pump (proposals)/Archive 135 § Proposal: Amend page title element to remove "Wikipedia, the free encyclopedia". —⁠andrybak (talk) 01:08, 4 November 2020 (UTC)[reply]
Support, hyphens are not used for this purpose, WP:NDASH.  Nixinova   T   C   02:23, 4 November 2020 (UTC)[reply]
  • Support. It's a tiny, tiny thing...but honestly, I would be happy to see it happen.—Neil Shah-Quinn (talk) 15:11, 6 November 2020 (UTC)[reply]
  • Support on enwiki per Armadillopteryx. 〈 Forbes72 | Talk 〉 16:28, 6 November 2020 (UTC)[reply]
  •  Comment: should an RFC be opened to gather more feedback? —⁠andrybak (talk) 16:01, 8 November 2020 (UTC)[reply]
  • Support – It shouldn't be a question that our interface should generally conform to the MOS absent any reason to the contrary. 207.161.86.162 (talk) 03:26, 9 November 2020 (UTC)[reply]
  • Tentative support, but I am wonder whether there is a technical reason that hyphens in page titles are so common, even for sites with strict style manuals. For example, both the New York Times and the BBC have hyphens in their page titles. Indeed, it looks like every site in my browser bookmarks that has equivalent punctuation has a hyphen (except that my university's Blackboard Learn site has both a hyphen and an en dash in the title, which looks quite ugly now that I have noticed it). Any thoughts about why that might be? blameless 21:01, 9 November 2020 (UTC)[reply]
    • Withdrawing my support per the below and continued investigation. It was said above that "hyphens are not used for this purpose"--I am certainly a descriptivist, and I would say that hyphens are used for this purpose for purely internet-based instances of language (such as browser tabs) that are entirely separate from prose content, for the sake of consistency and reliability across browsers and character sets. Neutral. blameless 19:26, 26 November 2020 (UTC)[reply]
  • Oppose or replace with pipe. Browser tabs have limited horizontal space, and the only effect of this proposal is to waste a bit more of it. Perhaps this is why it is so common to use a hyphen or a pipe rather than an en-dash or em-dash. ST47 (talk) 21:29, 9 November 2020 (UTC)[reply]
    ST47, I'd have thought that the pipe would take up less space than an endash. I've tested in Firefox and Chromium in Ubuntu. In Firefox the pipe takes up more space than endash (font Noto Sans 10pt). In Chromium both take up the same amount of space (I couldn't figure out which font is used). —⁠andrybak (talk) 23:06, 9 November 2020 (UTC)[reply]
  • My browser (Firefox on Debian) follows our page title (and every other page title) with " - Mozilla Firefox" so using a dash or pipe would make my browser title look weird. Is that enough to oppose? I don't know, but clearly hyphens are pretty standard separators in how browsers display page titles. Additionally, it's probably better that our page titles are ASCII-compliant, and this change would move us away from that. This could affect page downloads or distribution on offline hardware. My main concern is that we gain pretty much no benefit, but there might be hidden problems it introduces. — Wug·a·po·des​ 23:55, 9 November 2020 (UTC)[reply]
  • Meh Not worth the trouble for all the reasons Wugapodes mentioned. Probably nothing will break, but the benefit is so small it's not worth doing. The hyphen-minus is also the standard window title element separator on every non-Apple platform. An en/em dash will take up more space, which is undesirable. Switching to pipes would change the visual style, and I'm not a fan of that idea either (the hyphen-minus is the most common <title> separator anyway. --AntiCompositeNumber (talk) 00:27, 10 November 2020 (UTC)[reply]
  • Oppose Browser has limited space. Also, the proposal text doesn't clearly say which Hyphen#In_computing is currently used. Hyphen-minus is ASCII. If it currently is ASCII, then stay with ASCII for less interference with third party systems. TerraCyprus (talk) 23:26, 10 November 2020 (UTC)[reply]
    Sticking to ASCII is about 3 decades out of date, and is in general too limiting, even for English. Dicklyon (talk) 21:56, 10 December 2020 (UTC)[reply]
  • Meh (Is Meh a valid voting option?) The title is also used for bookmarks, and so the site suffix has some value there, but I generally edit the titles to make sense to me and normally remove the suffix. Most of the time the tab is too narrow to display all of the article title, so the "- Wikipedia" site suffix is lost anyway. Personally, I would delete the site suffix from the titles as the icon at the start is enough to identify the tab, but I do suspect that would be seen as a step too far — GhostInTheMachine talk to me 11:59, 14 November 2020 (UTC)[reply]
  • Meh because I'm not sure I'll ever encounter a Wikipedia debate that warrants "meh" as much as this one. I'm sympathetic to both sides, but would probably favor the character that can be entered with one tap of the keystroke and is easily identified by non-native English speakers who don't even know what an en- or em-dash is. On the other hand no one's really going to be typing this on their own. Also, what were French and Russian Wikipedias thinking when they instituted the em-dash? -- Fuzheado | Talk 20:46, 16 November 2020 (UTC)[reply]
  •  Comment: I have requested closure of this discussion at WP:ANRFC. —⁠andrybak (talk) 18:25, 23 November 2020 (UTC)[reply]
  • Support. The use of the hyphen here is an old "lazyism" from pre-MOS:DASH days. Should have been corrected a long time ago.  — SMcCandlish ☏ ¢ 😼  03:49, 8 December 2020 (UTC)[reply]
  • Support –definitely. It's professional English, and apart from being in accordance with the major style guides (including ours), it's slightly easier to read. I don't care if other languages want to stick with their shabby little hyphens. Tony (talk) 09:34, 8 December 2020 (UTC)[reply]
  • Yes, Support the hyphen is a lazy substitute for the intended punctuation, a dash of some sort. The spaced en dash is a good choice. Those who won't notice the difference won't be bothered. Dicklyon (talk) 06:58, 9 December 2020 (UTC)[reply]
  • Support. It's a very minor thing, but we may as well follow proper professional usage. Alkari (?), 10 December 2020, 04:29 UTC
  • Oppose Pretty much what Floq said. I don't have a real "side" as far as the actual issue, because, like most people, to me the distinction is essentially meaningless.(Please, please don't feel compelled to explain to me how very important it is) So, the only concern here is "will this break anything?" And it seems that a few people here are concerned that it might. So, very, very little benefit (arguably none at all) and some risk, so that's a no for me. Beeblebrox (talk) 00:04, 19 December 2020 (UTC)[reply]
  • Support. I found myself on both sides while writing this comment, but settled in support. The MOS is clear that an en-dash is preferred over a hyphen as a separator here. The most cogent objection is that the en-dash may cause certain technical issues, and there's a lesser point that it takes up more space. However, this same reasoning would apply to our many articles that are titled with – or — instead of -, or indeed any other non-ASCII characters, which all show up in the <title> tag. And yet, MOS:DASH has been in place for article titles for many, many years with no apparent problems. The fact that dewiki, frwiki, and ruwiki all use some form of dash also supports this point. We can always revert the change if we find out about some unexpected side effect. — The Earwig talk 06:11, 27 December 2020 (UTC)[reply]
  • Oppose If it works, don't fix it. Andrew🐉(talk) 13:00, 28 December 2020 (UTC)[reply]

Wikipedia turns 20 on 15 January 2021. Should we have a 20th anniversary logo for that day? This is a bit time sensitive as we can really only celebrate it once on 15 January 2021. Aasim (talk) 03:38, 30 November 2020 (UTC)[reply]

  • I'd like to add one puzzle piece to the right of the Ethiopic (at the top right). It would be barely visible, but symbolizes that over twenty years, we have added to the sum of human knowledge by bringing so much encyclopedic content to the world. VanIsaacWScont 03:56, 30 November 2020 (UTC)[reply]
    • That's an interesting idea - is there a single character version of "20" in any language that could be used? This could require a veritable bolting through however, since to get it used, it has to jump through a bunch of hoops on the WMF's side. Not that I suppose lacking the trademark on it is a concern for a one-off. Nosebagbear (talk) 10:37, 30 November 2020 (UTC)[reply]
      • Hebrew does, כ.--Wehwalt (talk) 11:04, 30 November 2020 (UTC)[reply]
      • There are dozens of options for number characters, including Aryabhata numeration, Hebrew gematria, Greek numerals, Babylonian cuneiform numerals, etc. I would like to keep the tradition of using an approximation of "wi" like the Tocharian "wi/vi" with the fremdzeichen form of "w" - . VanIsaacWScont 12:47, 30 November 2020 (UTC)[reply]
        • It strikes me that a stylized XX to emphasize the top half, which could be made to resemble a W, might be good.--Wehwalt (talk) 13:59, 30 November 2020 (UTC)[reply]
        • Pulling from various articles and such... Armenian Ի, Arabic ك, Attic/Greek ΔΔ, Eastern Arabic numerals ٢٠, Egyptian 𓎆𓎆, Aegean 𐄑, Phoenician 𐤘, Mongolian ᠒᠐, Ethiopic ፳, Glagolitic Ⰻ, Gothic 𐌺, Burmese ၂၀, and Hebrew כ as mentioned above... Plus, there are some languages that use a single character for twenty the word, like 廿. I think there are enough individual symbols meaning twenty to cover the globe, if people like the sound of that. --Yair rand (talk) 09:30, 8 December 2020 (UTC)[reply]
      20
      二十
      XX
      0x14
      What else? Aasim (talk) 17:48, 30 November 2020 (UTC)[reply]
  • I really like this idea. What can we do to make this happen? It's about a month away. Tony Tan · talk 09:36, 6 December 2020 (UTC)[reply]
  • Sounds good to me, too. As for what to do to make it happen, people with graphics skills should probably propose their designs and let us see them. Quickly.  — SMcCandlish ☏ ¢ 😼  04:55, 8 December 2020 (UTC)[reply]
A draft of the logo described by wugapodes
  • Hi everyone! Samir here from the Foundation's brand studio. Wanted to bring to your attention that we have recently published some celebratory Wikipedia 20 symbols here. Hope they can be of inspiration to your brainstorming. Please let us know if you would like to collaborate on something. Thanks so much for starting this discussion. --Selsharbaty (WMF) (talk) 10:54, 10 December 2020 (UTC)[reply]
    • @Selsharbaty (WMF): Thanks for sharing these! I want to ask if someone could design an image of a cell phone in that art style? (update, I made a stand-in myself, but feel free to keep tweaking) I have an idea for a logo we can use which represents Wikipedia's place in the development of knowledge accessibility. To keep the visual proportions the same, I think we should replace the puzzle globe with a four-quadrant square (instead of 4 images linearly). The top left would be File:WP20Symbols Wikiversity.svg representing paper encyclopedias; top right would be File:WP20Symbols_MediaWiki.svg representing the CRT monitors common when Wikipedia debuted; bottom left would be File:WP20 symbol CellPhone.svg representing our contemporary, mostly-mobile readerbase; and bottom right would be File:WP20Symbols_puzzleglobe2.svg to maintain continuity through the branding. Below this quadriptych would be the "Wikipedia 20" text mark. I've included a rough mock-up here using {{Multiple image}}. Does this generally sound like a good design? We've got less than a month to get something set up so if you could pitch this to your team and get feedback on changes, I'd be happy to help advertise a proposed celebratory logo to the community. — Wug·a·po·des​ 23:04, 17 December 2020 (UTC)[reply]
  • ping discussion participants @Awesome Aasim, Vanisaac, Wehwalt, Vanisaac, Yair rand, and SMcCandlish: Following up on Selsharbaty (WMF)'s message I used the WMF brand team's designs to make a logo displayed here (link for convenience). Since you all seemed interested, I wanted to get your opinions on it and possible revisions. If it's on the right track, we should coordinate an up-or-down RFC advertised at CENT or through a watchlist notice, and if it's the wrong track we should try to further develop other ideas in the next few days. — Wug·a·po·des​ 00:17, 18 December 2020 (UTC)[reply]
    Looks great! Maybe the first image should be a 20, though. Because Wikipedia turns 20. Aasim (talk) 00:57, 18 December 2020 (UTC)[reply]
    I'm... not really a fan of the style, tbh. It seems vaguely thematically wrong. (The entire set of resources provided seems quite off; the brightly-colored high-contrast thick-line cartoon-effect artwork looks somewhat childish and not really scholarliness/collaborative-project-themed. I find the faces a bit creepy, but that's just my personal sense of aesthetics, I suppose. Also, several of them are for broken links ("Bapho", "Ghyama", "WKTK (slang)", "Chic@s") and the Wiktionary one incorrectly describes "knowledge" as a proper noun, which is quite an error. I'm also a bit confused as to why six of the images have Islamic religious iconography? (None from other religions afaict.)) Anyway, back to the logo: I don't suppose we could go with something more along the lines of the commons:Category:Wikipedia 10 or commons:Category:Wikipedia 15 imagery? I do like the "20 years of Wikipedia" line, though. --Yair rand (talk) 04:54, 18 December 2020 (UTC)[reply]
    It's all an evil plot hatched by us Muslims: first we take over the Wikipedia logo, then we take over the world! All your pedia are belong to us. M Imtiaz (talk · contribs) 12:35, 21 December 2020 (UTC)[reply]
    I'd also rather see something thematically related to our past anniversaries and dislike the use of the cartoons.--Wehwalt (talk) 06:53, 18 December 2020 (UTC)[reply]
    Something as simple as a 20 with the zero formed by the Wikipedia globe, perhaps within an outline, would be fine.--Wehwalt (talk) 17:17, 18 December 2020 (UTC)[reply]
  • I would prefer something subtle, based on current or historical logos but without the flashy color. Something like the bottom-right one, but in the traditional grey, with the "radiating lines" removed and something to indicate "twenty" or "20" around the edges. If you do want to do a "4-image" logo, maybe use some of the earlier Wikipedia logos, or use logos for the Foundation, Commons, WikiData, and other cross-language parts of the project. Bottom line: The less it looks like the current or historical logos, the less I like it. davidwr/(talk)/(contribs) 🎄 16:48, 18 December 2020 (UTC)[reply]
    I don't think I'll have much aesthetic input, as long as the messaging purpose is done well, and we take accessibility into account (black and red don't mix well, because red looks near-black to people with some kinds of color blindness). I'm not sure the "reading a book" thing has much to do with Wikipedia, though the desktop and mobile icons or whatever we might call them are on-point.  — SMcCandlish ☏ ¢ 😼  04:31, 19 December 2020 (UTC)[reply]
  • Thanks for the feedback. I've worked up three candidates based on the stated preferences and previous years.
  • Still in the WMF's planned visual style, but not so different as first iteration.
    Still in the WMF's planned visual style, but not so different as first iteration.
  • Our usual puzzle globe with the "20 years of Wikipedia" mark.
    Our usual puzzle globe with the "20 years of Wikipedia" mark.
  • A banner inspired by the Wikipedia 10 visuals.
    A banner inspired by the Wikipedia 10 visuals.

I'll wait a couple more days for additional feedback, and absent any major problems I hope to get an RfC started by the end of the week. — Wug·a·po·des​ 02:55, 22 December 2020 (UTC)[reply]

Cite username policy when signing up

When singing up on Wikipedia, you have to make a username, and unbeknownst to newcomers, there is a username policy that controls what kinds of names are allowed and vice versa. I've seen a ton of newcomers using prohibited types of names. A significant portion of them do not have a malicious intent; they think anyone can make a user account on Wikipedia, like accounts on YouTube, Instagram, etc. Then, an admin would message that they are subject to admin attention, scaring them. There are those who just ain't here to build, but there are those who, just as they are about to do good-faith edits, got blocked from editing for violating the policy, which they are unaware of. You could've told me!

To prevent these cases from happening again, I propose referencing the policy at the signup page, below or above the entering username bar. That way those willing to signup and are about to make a violating username can be aware. It could be small stuff like PLEASE READ OUR USERNAME POLICY TO SEE WHAT NAMES ARE NOT ALLOWED ... or big stuff, listing what names are not allowed in short, bulleted lists, like:

PLEASE DO NOT USE THESE TYPES OF NAMES:

  • Names that represent an organization
  • Names that are promotional
  • Names that imply multiple people using your account
  • Names that include a role or title within an organization
  • Offensive or explicit names
  • Confusing or long names
  • Names of people that has a Wikipedia article
  • Names intended to troll, vandalize, disrupt, advertise, or spam Wikipedia

GeraldWL 12:45, 9 December 2020 (UTC)[reply]

  • Are there really a significant number of good-faith editors being blocked on sight for username violations? Can you provide a specific, recent example of an editor immediately blocked for having, for example, a username "intended to troll, vandalise, disrupt, advertise or spam Wikipedia", who actually intended to be constructive? – Teratix ₵ 13:08, 9 December 2020 (UTC)[reply]
    WP:Usernames for administrator attention begins with a big scary pink box urging us only to report usernames guaranteed to cause an immediate apocalypse: Do not report a username merely because it “appears" promotional, etc. However, a significant number of good-faith editors create names such as "Foo people" or "WidgetCorp". As such names clearly infringe the username policy but we are explicitly warned not to report them, it might be better for everyone if new editors were encouraged to use a more appropriate name in the first place. Certes (talk) 13:19, 9 December 2020 (UTC)[reply]
    It may actually be preferable if "WidgetCorp" was not explicitly warned that organisations' names are prohibited as usernames, because, at least in my experience, the vast majority of accounts with corporate usernames like this are promotional SPAs with conflicts of interest. The username in this case acts as an obvious warning sign, inviting closer scrutiny of their editing. If an editor starts whitewashing Widget Corporation, they'll be spotted and reverted faster if their name is "WidgetCorp", because usernames like these are such an obvious red flag. Warning new editors against these sorts of representative names would reduce the effectiveness of this tactic. – Teratix ₵ 13:46, 9 December 2020 (UTC)[reply]
    Teratix, I frankly don't understand this part. Linking the username policy on the signup page and make it obvious for newcomers to see will reduce the likeliness of cases happening. It's like if you put a sign saying that there's construction ongoing and don't go near it, the likeliness of people entering the area is reduced. When you say that "The username in this case acts as an obvious warning sign," you're hinting that such usernames usually do bad-faith edits, which is a false claim. It sounds like we're purposefully not linking the policy in order to investigate bad-faith accounts, which I believe there can be various alternatives. It doesn't have to play trick on the users. It's like saying "We'll not tell anyone that we have a civility policy, see if anyone becomes uncivil." GeraldWL 03:12, 10 December 2020 (UTC)[reply]
    In my experience with accounts named after organisations, those with completely problem-free edits are overwhelmingly the exception rather than the rule. Nowhere did I say or imply that such usernames usually do bad-faith edits, merely that their edits tend to be problematic and deserve further scrutiny (one can edit in good faith but nevertheless make poor edits). It's like saying "We'll not tell anyone that we have a civility policy, see if anyone becomes uncivil." Would that be such a terrible idea? Surely anyone who needs to be explicitly directed to a civility policy before they begin interacting nicely with other editors is likely to be a net negative to the project? (I don't mean "outright conceal the existence of WP:CIVIL", just not explicitly informing new editors of what should be common sense – treating others with respect).
As others have noted, the username policy is linked from the sign-up page. – Teratix ₵ 11:13, 10 December 2020 (UTC)[reply]
Teratix, the policy is cited in the page, but not so obvious. The words "help me choose" sounds like a random name generator if you have no idea how to pseudonymize yourself. I believe there are many ways to tackle a bad-faith editor, or an editor whose edits are unconstructive, than not warning them of a policy they should've known in the first place. That's just my take, ofc. GeraldWL 11:32, 10 December 2020 (UTC)[reply]
Yes, I agree that the link's wording could be improved. – Teratix ₵ 11:34, 10 December 2020 (UTC)[reply]
  • It's a sensible and user-friendly approach to tell new editors the rules about user names before they create one. Warning templates after the fact, or even gently-worded manual warnings, can have a chilling effect on someone brand new to the community. My preference would be for a link to the policy because (1) the summary list would make the create-account screen ridiculously long on mobile and (2) it introduces the new editor to the idea that Wikipedia has policies, plus on that page they'll see the box of other conduct policies. Schazjmd (talk) 15:50, 9 December 2020 (UTC)[reply]
    • "My preference would be for a link to the policy" The sign-up page already links to the policy. Do you mean changing/adding wording to that? —  HELLKNOWZ   ▎TALK 16:03, 9 December 2020 (UTC)[reply]
      • This. The signup page says (help me choose) linked to this policy right on the box where you type in the name you want. — xaosflux Talk 16:52, 9 December 2020 (UTC)[reply]
      • That page also has this banner at the top of it: MediaWiki:Signupstart, which could be expanded some if helpful. — xaosflux Talk 16:53, 9 December 2020 (UTC)[reply]
        • Wow, I did not expect the policy page to come up from that! I didn't click it when I checked out the page because I thought "help me choose" would assign a random name (based on my experiences with other websites). Yeah, we could use clearer wording there. Schazjmd (talk) 17:17, 9 December 2020 (UTC)[reply]

So the create-account page has a link to the policy but it isn't clearly indicated. Maybe change Help me choose to What are the rules for names? ? (Hopefully other editors will have better ideas, that's the first one that came to my mind.) Schazjmd (talk) 18:11, 9 December 2020 (UTC)[reply]

Schazjmd, I would make that slightly bigger-- make it more obvious for newcomers to see. That means no brackets, as having them makes it seem useless (or at least that's just how I feel). Of course, this approach won't solve it all, but at least it helps. IMO. GeraldWL 03:03, 10 December 2020 (UTC)[reply]
  • I wouldn't give it the tone of a "warning" (so not as phrased above, with all caps and bold), but I think welcoming guidance about the username policy would be helpful to people registering an account and would save them a potential headache. Some people may not realize the implications of choosing a username that has their company's name in it, or their own name (e.g. verification procedures), etc. Levivich harass/hound 03:37, 10 December 2020 (UTC)[reply]
    Levivich, agree. GeraldWL 03:39, 10 December 2020 (UTC)[reply]
  • I can understand why the "help me choose" phrase seems a bit cryptic. I think "username guidelines" or even just "guidelines" would be far clearer wordings. However, I am reluctant to include a huge amount of detail about what usernames are and are not acceptable, mainly because the bulk of such guidance would be irrelevant to good-faith users (will a helpful editor really need to be told not to select an offensive username?), but also because problematic usernames can act as a convenient signal that a users' contributions need closer examination. – Teratix ₵ 11:27, 10 December 2020 (UTC)[reply]
Support improving the wording. Both of these sound good: "Please check our username policy" (request/instruction) or "What are the rules for names?" (a question the user could relate to, and less formal). Pelagic ( messages ) – (07:56 Mon 14, AEDT) 20:56, 13 December 2020 (UTC)[reply]
  • Support the wording change per User:Pelagic above. GenQuest "scribble" 21:58, 21 December 2020 (UTC)[reply]
  • Strongly oppose. First, nobody is actually going to read it. I bet half the established editors around haven’t read the username policy either. I’ll openly say I only know some parts of it. Totally unreasonable to link that page and expect people actually read it. The more text and links you add, the less chance people will read or click on *any* of them. Second, if someone is here just to promote I’d rather they choose a promo name and make it real easy for us over at COIN. Username violations are fine, it makes their intentions much easier to spot. If they chose a less violating username, that doesn’t magically make their intentions more pure. ProcrastinatingReader (talk) 22:36, 21 December 2020 (UTC)[reply]
    ProcrastinatingReader, it is dangerous to assume nobody will read it. Nobody will seemingly read Wikipedia's Disclaimers, but is it safe to assume nobody actually does? We expect people to "comply with the rules" but don't hand them the rules in the first place. Usernames violations are not fine as they're breaking Wikipedia's rules, so that's why I'm bringing this proposal, because it is still a policy. If the username policy is just a tool for admins to jumpscare the offending usernames, then why is there even a username policy? GeraldWL 13:45, 22 December 2020 (UTC)[reply]
    It's fairly safe to assume this. We have ~50 policies, and god knows how many guidelines, plus the MOS, and then essays which de facto are accepted as guidelines. I have not read most, and I assume most editors haven't either, and even most admins who do not work in username policy enforcement (thought: I wonder how many admins would pass a general PAG quiz).
    This is why we give warnings to people. It's why we have username soft blocks. Common sense gets you very, very far in any collaborative or social environment. And common sense tells us certain usernames are inappropriate (as they would be anywhere).
    I hope a user signing up doesn't read the username policy. If they want to spend their time reading a long wall of text, there are more helpful policies to be reading. Or, rather, essays, on how they can write content better, or just writing content, or doing literally anything else. We should stop wasting people's time by expecting them to read our legislation books, especially when they likely weren't about to fall foul of them anyway. Just as we don't expect people to read the entire statute books or the state's rules on what names are acceptable on a birth certificate (this exists, in many jurisdictions). The registrar will tell you if there's a problem. ProcrastinatingReader (talk) 14:41, 22 December 2020 (UTC)[reply]
    ProcrastinatingReader, this doesn't erase the fact that citing the policy in a visible way may help attract some. I do not guarantee the solid effectiveness of this, but if this can help even a dozen of newcomers, why not? I can understand the opposition, that through experiences of being warned is the best way of developing WP IQ. But a lot of people just want to edit immediately. Then they have to deal with an admin noticeboard BS? I think that not warning them of such wow so important policy is a symbiotic mutualism: AGF newcomers can edit without the need to deal with woa-woa-woa admins, and admins can have time for other things than to care about a small thing as a username. GeraldWL 14:48, 22 December 2020 (UTC)[reply]
    The username requirements are not just bureaucracy. They give a good indication into the kind of editing an editor will be doing. If you spend some time at eg WP:COIN you'll see how helpful usernames are in that sense. An editor who is here solely to promote is saving us a lot of time by making their intentions very clear using their username. An editor with an egregiously offensive username is obviously not here to build an encyclopaedia. Making it more obvious that they should choose a normal name will just help them keep up their crap for longer, and waste more volunteer time in determining their purpose here. If we're blocking people for small technical violations, then something should change there. ProcrastinatingReader (talk) 15:00, 22 December 2020 (UTC)[reply]
    ProcrastinatingReader, I believe that this proposal would not disadvantage that tactic, which I believe is a smart one. Here's the logic: some majority editors may look at the policy and properly learn first before making an account. Offending paid editors or COI editors, however, may not give a shit and just make an account and do 10 edits in a sandbox just to get editing privileges. As you said, not all will look at that policy-- maybe the majority of that people are the offenders. I've lived my childhood with bullies-- trust me, ignorance does not pay attention to details. GeraldWL 15:15, 22 December 2020 (UTC)[reply]
    correction: *some genuine editors. GeraldWL 15:16, 22 December 2020 (UTC)[reply]
    Most editors do not sign up with the goal of becoming prolific editors. They sign up to edit a small typo or something. That's why I signed up. I can tell you now I would not have read the username policy, and still only know the principles. An editor with the goal of getting their promo published will have cared more for policy than I, because they actually have a motive. If someone made me decide between "read the policy and sign up" or "don't read the policy and you can't edit", I'd probably have chosen the latter, simply because I wouldn't care enough to spend my time reading 3000+ words to edit a typo. ProcrastinatingReader (talk) 15:19, 22 December 2020 (UTC)[reply]
    ProcrastinatingReader, "An editor with the goal of getting their promo published will have cared more for policy than I"-- well, you just... go and see the many paid editors on Wikipedia. They don't give a shit, my man. It's the I don't care, just leave me alone making articles about my very cool furry website ideology. As I state, this change will not be fully effective in preventing good-faith editors from being blocked, but this may help. GeraldWL 15:29, 22 December 2020 (UTC)[reply]
    Do you have some examples of accounts of good-faith editors who were blocked due to username policy violations? That'd be helpful to picture the issue here. ProcrastinatingReader (talk) 15:32, 22 December 2020 (UTC)[reply]
    ProcrastinatingReader, I cannot give specific examples of such users as I'm not prepared for such threads when I posted this proposal. However, from my witnessing of various unjustified blocks, I'm sure there are victims of such that have suspicious usernames as a cause. A lot of us make an account in good faith, so if an AGF editor is warned because of violating a policy they could've been given when singing up, isn't that disappointing? By the way, the username policy is already cited in the signup page-- it's just not given clearly (rn it says "help me choose which sounds like a random name generator). I'm just proposing for a clearer text, since the current text is not correct.
    To prove the no-harm-ness of this proposal: the policy's been there for long, and we can still track down offenders. Suppose paid editors are detailed in learning policies to mask their violations. That's simply not the case. GeraldWL 15:46, 22 December 2020 (UTC)[reply]
    The argument here is that the link is too obscure to be noticed by 'good-faith editors'. The same would apply to any other editor signing up, then, including paid editors. And any change would affect anyone registering, too. I simply hypothesise that the vast majority of good faith editors would not mistakingly fall foul of the username policy. Without specific examples to go by I cannot really judge that there's a real problem here, or that this is the best solution to fix it. But I am quite confident that such a change will disrupt anti-vandalism/COI efforts. I'll drop a link at COIN for additional thoughts, in case others active there see this differently than I. ProcrastinatingReader (talk) 15:55, 22 December 2020 (UTC)[reply]
    ProcrastinatingReader, if you think that nobody will spot it, then why do you think it will disrupt anti-vandalism efforts? The fact is that many confuse Wikipedia with social media: in social media, there are no rules on your usernames, so long as it is in their character threshold. In Wikipedia, no, policy creeps you throughout. I'll bow down in this sub-thread as we arguing here continuously won't give additional value, however any editors willing to express opinions may do so. GeraldWL 16:03, 22 December 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]
@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)[reply]
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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]
    @Iridescent: As stated in the A2 description, "this would also allow local overrides". Thanks. Mike Peel (talk) 09:17, 12 December 2020 (UTC)[reply]
  • 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)[reply]
    @Keith D: Can you elaborate on how that 'makes it easier for users' please? Thanks. Mike Peel (talk) 21:03, 11 December 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Support A2 and B. The typical editor does not need to edit technical interproject links. Ruslik_Zero 20:38, 13 December 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • Oppose A1, week oppose on A2 and support A3 for the reasons outlined by Iridescent. -- Euryalus (talk) 23:12, 15 December 2020 (UTC)[reply]
  • Oppose A1, A2, B, - Support A3 for reasons above already given. Only in death does duty end (talk) 15:36, 16 December 2020 (UTC)[reply]
  • 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)[reply]
    @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)[reply]
  • 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)[reply]
  • Strongly support A2 from my point of view this is at this moment the best solution. Robby (talk) 21:53, 19 December 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]

That Non-Published Text Inside The Text-Editing-Box Be A Different Colour (Such As Green)

When editing a Wikipedia page there can be a lot of extra text (such as reference information) that isn't going to published on the finished Wikipedia page, to make the editing of the publishable text easier, it would be helpful if the non-published text was shown on screen in a different colour (such as green).

This would help to distinguish the different sorts of text from each other.

As an example of how this might work, programs used to edit software code, (including HTML webpage code) often use different colours for different types of characters, and different sections of the code being edited.

Options could include :-

  • switching off the colour(s), to show monochrome, as is currently the case.
  • allowing each user to select which colour(s) they want each section of text to be, while they edit it.

Implementing this simple change might increase the productivity of editors, as they edit Wikipedia pages.

@WikiWikiWonderful: There already multiple options for syntax highlighting when editing wikitext. Under Preferences -> Gadgets you can enable syntax highlighter or wikEd. There is also CodeMirror but I'm not entirely sure how to enable it. And if you use VisualEditor, you won't see any non-rendered wikitext at all. – Joe (talk) 16:08, 15 December 2020 (UTC)[reply]
Joe Roe, CodeMirror is available by default for all users in the editing toolbar, as a marker icon (before Advanced). Or as "Syntax highlighting" in the 'hamburger' drop down menu if you are using the 2017 wikieditor. —TheDJ (talk • contribs) 21:25, 22 December 2020 (UTC)[reply]
This proposal is about highlighting the difference during the edit. It would make it easier to find your place and keep track of what you have done. It must not interfere with syntax highlighting, which serves a different purpose. · · · Peter Southwood (talk): 05:49, 18 December 2020 (UTC)[reply]

Minus signs not rendering

The minus sign sometimes does not appear in equations. For example, the first minus sign in the following equations does not appear in a Chrome browser on my laptop computer:

Please see Talk:Modular arithmetic#Minus signs not rendering and Talk:Abel–Ruffini theorem#Poor rendering with Chrome is confusing.—Anita5192 (talk) 17:11, 20 December 2020 (UTC)[reply]

@Anita5192: This has been reported multiple times now on WP:VPT, which would have been the correct place to leave this comment. --Izno (talk) 18:11, 20 December 2020 (UTC)[reply]
I don't see it there anywhere.—Anita5192 (talk) 20:02, 20 December 2020 (UTC)[reply]

Add the stations at Template:Adjacent stations

Not a project-wide concern. Please propose at Template talk:Adjacent stations. (non-admin closure) {{u|Sdkb}} talk 03:33, 22 December 2020 (UTC)[reply]

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.

Line 6, 8, 9, 17 and extension of 18 of Chengdu Metro have been opened, but the template don't update these stations, please update it.--Nrya (talk) 01:12, 21 December 2020 (UTC)[reply]

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.

Overhaul of talk page editing

As a reader of Wikipedia rather than an editor (or at most a very occasional editor) something I always think is a major drawback of the whole project is the bizarre and confusing system of talk page "editing", which is basically the same as editing an article and in my experience utterly unsuited to a discussion scenario.

Surely a far better method would be one more akin to an online forum, where to begin a thread, or post on an existing thread, the user simply types in a dialogue box (or whatever the correct term is) and the whole experience, especially for the uninitiated, is far clearer and simpler (and safer - no chance of inadvertently editing or deleting previous comments).

I'm sure there must be thousands of people with knowledge of a subject or other potentially useful input, whose thoughts and observations would help to improve articles, who are put off making any remarks on talk pages due to the confusing and unusual way in which comments must be added.— Preceding unsigned comment added by 2a02:c7d:93e9:b500:b09e:6a2a:d36f:9f2c (talk • contribs)

Yes! I think you’re right here. This sounds somewhat like what Flow tried to (unsuccessfully) do. Unfortunately this is something in the domain of the Foundation. It would take too much time to expect a volunteer dev to code it, and even then it’d need to be signed off by some people in product, so really this has to be a funded project from them. I’m not really sure where the right place to raise this is, but maybe someone more familiar with the product structure of the WMF may know? Probably somewhere on meta wiki. ProcrastinatingReader (talk) 13:02, 22 December 2020 (UTC)[reply]
Several initiatives such as Flow have aimed to make talk pages more accessible, especially to novice editors. However, the current method has stuck, because it's familiar to everyone who knows how to edit an article. Of course, many potential contributors are experts in their field rather than in article editing. DiscussionTools and other gadgets can provide a friendlier interface to the existing format. Certes (talk) 13:09, 22 December 2020 (UTC)[reply]
I like DT but I’m not sure it helps people unfamiliar with our format. It makes replying easier/faster but talk pages are still a hard-to-navigate clutter. ProcrastinatingReader (talk)<
@2a02:c7d:93e9:b500:b09e:6a2a:d36f:9f2c:, one significant reason for the current format is it lets you do anything you could on an article page - trying to make a system that is both user-friendly as a normal chat set-up and still has all the functionality of the current one is extremely tough. There are some current work, now quite advanced, to make at least the general communication aspect much more user-friendly. It's still a bit buggy, and needs more functionality, but much improved on 3 months ago. We'll definitely see rollout here in 2021. Nosebagbear (talk) 17:06, 22 December 2020 (UTC)[reply]
I think our current talk page system works great overall. Full stop. (There are a few areas of improvement I would suggest, that I expect will eventually become available if we don't make a sea change to a new framework, that I am keeping mum on as beyond the scope and the grain of this thread). The fact it does not resemble other forum systems is in my view a plus. A slight barrier to entry, for a fully comprehensible system once you learn it—where learning it teaches a variety of minor skills that will be needed, in any event, in more complexity and abundance to edit articles (when I say that I am taking into consideration the visual editor, and discounting it as near useless for involved editing)—helps weed out those not sufficiently interested, knowledge-sharing-hungry, and smart enough to likely ever become great editors. At the same time, our system is just as easy to learn as forums with respect to a lot of older retired academics and professionals with all their accumulated expertise, who in my experience don't share much of a Venn diagram overlap with those who are coming here used to forums and seeing a different system than they are used to, and make up a lot of new users who are actually here to build an encyclopedia.

On that last issue (despite the change to the AfC "barrier") a huge percentage of our new articles for the past few years are undisclosed paid editing, copyright violating, advertisements. That problem is so unrecognized, massive in scale and dangerous to our long term efficacy, that it's hard for me to talk about without trembling in anger and frustration that it's not the near exclusive focus of regular editors and the foundation to address. It colors everything, and making talk page editing more forum-like would, I think, contribute to that problem as a side result.--Fuhghettaboutit (talk) 17:26, 22 December 2020 (UTC)[reply]

no Disagree @Fuhghettaboutit: with due respect, I could not possibly disagree more strongly with the idea that we intentionally ought to have technical barriers to entry to weed out newcomers. The editors who we lose by having those barriers are not mainly UPEs—they're mainly women, non-tech savvy people, and the other groups we most desperately need to address Wikipedia's systemic bias. I'm fully onboard with combatting the crud that clogs up AfC/NPP, which is indeed a huge problem, but we should tackle it in a targeted way, not by abandoning our commitment to be welcoming to newcomers, which would create mostly collateral damage. {{u|Sdkb}} talk 19:56, 22 December 2020 (UTC)[reply]
You add to my point, because the issue is not tech savviness. Our system is not harder to learn than others. The issue is learning a new way to post to those who are already used to another system. People who are not tech savvy are more likely to be unfamiliar with forum systems and so it's far more likely to be neutral as to them. Meanwhile, biting is about human treatment of newcomers with kindness and patience; it's about [lack of] hostility in human interaction. I wholly reject the idea that what I am talking about even interfaces with that concept—and have spend a great deal of my time here, over 15 years, trying to shepherd new users with friendly interaction. The rub though is in calibrating the systems so that, on balance, we maximize the likelihood of getting good new users, and tend to funnel away those who have no such potential.--Fuhghettaboutit (talk) 21:26, 22 December 2020 (UTC)[reply]
Fuhghettaboutit, in my opinion anyone who thinks talk pages 'work great', should also farm their own food and be denied entry to a supermarkt, farming your own food also works great, we should make everyone do that ! —TheDJ (talk • contribs) 21:34, 22 December 2020 (UTC)[reply]
Hey DJ. Sorry, but your analogy couldn't be more is inapt in my view. It is to something almost none of us do, that is well known to be naively thought easy when it's actually incredibly complex, finicky, labor intensive and super limiting. First, there is no stand in for the unknown quantity (our system versus a forum system are two completely known quantities by most of us). Therefore, having used both extensively, I directly come to my judgement call that there's little advantage of one over the other. Additionally, using talk pages here is something most of us do everyday (are doing right now); that we actually see most people figure out fairly easily; and it is something we had to figure out ourselves when we arrived here – for me, in 2005, when it was actually more difficult. I remember. It was easy. And yet I remain relatively tech naive, and was far moreso in 2005.--Fuhghettaboutit (talk) 22:05, 22 December 2020 (UTC)[reply]

Since the OP speaks as an IP reader and not editor, we could display the talk page in a more friendly format, for users not logged in. Editing would remain as normal. The page rendering would parse the talk page and turn it into a friendly non-Wikipedian format (which is the hard part). If this irritates IP editors they should sign up for an account there are a number of things not available to IP editors this could be another. -- GreenC 17:57, 22 December 2020 (UTC)[reply]

I agree with OP, we're basically using internet-equivalent of stone-age tools to communicate, and it hugely hampers the growth of our editing pool and of the projects overall. An overhaul is so long overdue. Flow was an attempt but they gave up after that. I agree it's in the WMF's domain, and when the WMF holds trustee elections, I plan on asking the trustee candidates some questions about how much money they're going to allocate to this sort of development as compared to how much money they allocated in FY 20-21. Levivich harass/hound 18:13, 22 December 2020 (UTC)[reply]

My sense is the lack of uptake of VisualEditor was a lesson that WMF can't force the community to change even after spending lots of time and money on a project. There would have to be user choose which they prefer. Which is why my proposal above to use one style for IP readers by default for display, and the classic style for everyone else by default, and in both cases the 'editing' of a page remains the classic wiki style. A hybrid to start. After time editors will naturally ask the editing be migrated to a new style as well. Step by step is the way for large complex political changes. -- GreenC 18:40, 22 December 2020 (UTC)[reply]
People adopt new technologies quickly if those new technologies are good. Just ask Apple. Levivich harass/hound 18:44, 22 December 2020 (UTC)[reply]
Maybe, but we are not Apple selling smartphones. Again look at VisualEditor which is the best analogue. VE is great technology. -- GreenC 18:47, 22 December 2020 (UTC)[reply]
VE is not great technology, it's a poor WYSIWYG editor by modern standards. Back to talk page editing, the technology for us to communicate over the internet (better than this editing-a-text-page nonsense method we're using now) already exists. WMF doesn't have to invent anything new. Editing Google docs simultaneously without edit conflicts has been around for years. Message boards have been around for decades. What's needed from the WMF is to adapt the best existing technologies for Wikipedia's use (which it should do with a strategic partner); the WMF doesn't need to re-invent the wheel here. I don't think the community is resistant to change so much as it's resistant to change for the worse. Levivich harass/hound 18:52, 22 December 2020 (UTC)[reply]
If you're comparing the editor with Google Docs, it didn't have a legacy format problem. Word did, but Microsoft had a lot more money and incentive to make it work, and even they replaced their old legacy format with an XML-based one.
The key issue with change is, as with so many things, English Wikipedia's consensus-like decision-making process. Generally, the community tries very hard to agree on something that most editors can live with. There is a significant number of vocal editors who like using the same syntax as editing articles on talk pages. (Some of them don't follow the usual indenting conventions for talk pages, but hey, as long as they don't mind when someone else fixes it, I guess I can't complain too much.) There's a reason why linear discussion board threads remain popular on the web: you just need to find where you last left off and catch up from there, rather than trying to chase down innumerable branches that have popped up. But many people like greater freedom to post wherever they want. We'll have to see if the discussion tools initiative improves matters. isaacl (talk) 19:42, 22 December 2020 (UTC)[reply]
The Talk pages project and mw:Talk pages project/New discussion are interesting, but they're mostly convenience factors for existing editors imo. Whilst these will help new contributors too, I am not sure they address the fundamental problems. They make it easier to technically reply to a comment, but they do not make it easier for someone new to jump into the mountain discussions we have around here. They don't make finding discussions easier, or searching through them, or organising them. Some of the issue I think is the format of discussions, both software and 'social'. Social format alone can make a massive difference: compare the format of ANI to the format of AE for resolving problems; one more often ends with conclusive outcomes.
That said, they've identified some of the right issues. See mw:Talk_pages_project/New_discussion#Background. Some of this falls upon us. For example: Junior Contributors find the workflow difficult to discover. Many talk pages contain large yellow infoboxes. they, "...are so prominent they distract people from most important actions on a talk page (start a new topic, reply, edit, etc)." The WMF can't force a change here without causing drama. Within the community, trying to remove the talk page crap is an uphill battle. Maybe the foundation can create a better area in the page to host this fluff, like a button in the toolbar, and some kind of "talk page banner priority system" (info, warn, etc). They got around this on mobile by taking the decision out of the community's hands and moving it all into "About this page". Some of the issues are from a community POV, eg signing edits is not the biggest barrier for the newbie (someone else can {{unsigned}})
I think some folks in the community working with some folks in the foundation, and some connection with external experts, could lead to a good outcome here. ProcrastinatingReader (talk) 20:08, 22 December 2020 (UTC)[reply]
It's a very solve-able problem. Which isn't to say that it's easy or quick or cheap, but it's doable. WMF faces some unique challenges. Legacy is one; scale and speed are probably bigger concerns. But there are database and network architects out there who are very knowledgable and good at tackling these sorts of problems. The best ones are in well-paid jobs in the private sector, many at those big companies I won't bother naming. We need a team of those people to spend a year or two coming up with a better UI for Wikipedia editors. They need to have discussions with the community to figure out user needs, but it needs to be experienced software architects asking the questions (not community liaisons), and overseeing the dev teams. The best devs need to talk to the end users directly. It can be done, it just takes spending real money in the right way. Levivich harass/hound 20:19, 22 December 2020 (UTC)[reply]
The key issues are not technical, in my opinion, but social. At present, I believe there are enough editors who think the WMF should leave the site mostly as is (other than investing in the features and tools of interest to them, natch) that it would be unappealing to invest in a prolonged engagement with the world-wide community when there is significant doubt that the result will be accepted. isaacl (talk) 21:13, 22 December 2020 (UTC)[reply]
There’s a vocal number of people who refuse to accept a change to their workflow, but I am not convinced the majority is stubborn or illogical. I suspect (or at least hope) that if what Levivich says happened and there was a good end result, those dissenting voices would be dwarfed by those which are excited to try something better. I’m hoping the poor precedent is a mixture of this set of people + those who just dislike the implementation, not the principle. ProcrastinatingReader (talk) 21:49, 22 December 2020 (UTC)[reply]
I think it's more of a tragedy of the commons: people are happy with methods that work well for them personally, even if it causes a burden on the collective community. The thing is, collaborative editors don't want to dwarf the voices of others; they really want to find a compromise that as many people as possible can go along with (a true consensus). It's not a lot of fun arguing against long-time, valued contributors, and so people move on to other things instead. isaacl (talk) 01:39, 23 December 2020 (UTC)[reply]
  • This is already happening. The IP has a very valid point, but many of the editors above seem to have missed the link to the Discussion Tools extension being built by the WMF that seeks to tackle this exact problem and will be rolled out in the coming year. It's a waste of energy to highlight the need for the WMF to address this problem when they are already doing so. {{u|Sdkb}} talk 20:03, 22 December 2020 (UTC)[reply]
  • This is one of those ares where the Wikipedia process has failed. Editing talk pages as if they were articles leads to an exacerbation of our systemic bias towards people with technical ability, who (speaking as someone who worked in technical areas of IT for several decades myself) have very little correlation with people who can create a decent encyclopedia. This seems to be a topic where most people who think about it recognise there to be a problem, but there's little agreement on what to do about it. Phil Bridger (talk) 20:53, 22 December 2020 (UTC)[reply]
  • Hey Iridescent, any thoughts on this one? I think I've seen you comment on interface before, though not talk pages in particular. ProcrastinatingReader (talk) 22:30, 22 December 2020 (UTC)[reply]

Why would we want to make talk pages different from other pages on the site? Assuming it did lead some people to comment, we would still be better off if they became editors rather than trying to interpret what they want us to do. If they do go on to edit, they will still need to learn how to do that. --Khajidha (talk) 23:30, 22 December 2020 (UTC)[reply]

With VE? Not really. ProcrastinatingReader (talk) 23:44, 22 December 2020 (UTC)[reply]
As someone else noted earlier, VE is near useless for anything beyond correcting typos.--Khajidha (talk) 00:09, 23 December 2020 (UTC)[reply]
Why do you think that? (or, what shortcomings make it useless for you?) When I write articles I tend to prefer using VE personally (though I do often need to switch to source, mainly to edit templates). ProcrastinatingReader (talk) 13:22, 23 December 2020 (UTC)[reply]
Template editing is one major problem. Heck, link editing is much simpler in source mode, as I can edit the link itself and its pipe all at once just as easily as I would edit any other word on the page.--Khajidha (talk) 14:35, 23 December 2020 (UTC)[reply]
The Foundation semi-recently celebrated reaching 50% of first edits being made with VE, and also noted that 35% of subsequent edits by those users are made with VE. To drop from 50% to 35%, a little math quickly establishes that VE either drives upwards of 30% to quit editing completely, or that users given VE rapidly find and flee to the Wikitext editor, or some combination. They didn't supply sufficient data to distinguish which.
They want to convert mobile to default to VE. They ran a randomized test were mobile users were given either VE or wikitext editor, 50%-50%. They never released the results. The comments on the Phab task made it clear that the results were extremely bad for VE. A substantial portion of people quit before VE could even finish loading. Every time the Foundation collects data on the real world impact of VE, the data shows giving users VE has a negative impact.
Returning to the Talk page subject, the Foundation's crusade to replace Talk pages with Flow chat-boards was grossly broken. They fought for six years trying to force the project forwards, ultimately terminating development and deployment. The MW:Talk pages consultation 2019 resulted in Global Community Consensus to build enhancements on top of existing talk pages. The new MW:Talk pages project is adding easy reply links to existing talk pages, and possibly other enhancements. Alsee (talk) 03:47, 25 December 2020 (UTC)[reply]
Visual Editor is so useful for citing scientific research papers that I wouldn't use Wikipedia without it, manually citing hundreds of scientific papers would be a massive pain otherwise. Hemiauchenia (talk) 23:00, 25 December 2020 (UTC)[reply]
@Hemiauchenia: I used to rely on the Cite button in VE in source mode for that exact reason (and still use it on occasion). That Cite button Citoid. I stopped using it when I found WP:Zotero. They do the same thing, but Zotero does it better:
  • What Citoid spits out for https://pubmed.ncbi.nlm.nih.gov/32202722/:
    {{Cite journal|last=Emanuel|first=Ezekiel J.|last2=Persad|first2=Govind|last3=Upshur|first3=Ross|last4=Thome|first4=Beatriz|last5=Parker|first5=Michael|last6=Glickman|first6=Aaron|last7=Zhang|first7=Cathy|last8=Boyle|first8=Connor|last9=Smith|first9=Maxwell|last10=Phillips|first10=James P.|date=05 21, 2020|title=Fair Allocation of Scarce Medical Resources in the Time of Covid-19|url=https://pubmed.ncbi.nlm.nih.gov/32202722/|journal=The New England Journal of Medicine|volume=382|issue=21|pages=2049–2055|doi=10.1056/NEJMsb2005114|issn=1533-4406|pmid=32202722}}
  • What Zotero spits out for https://pubmed.ncbi.nlm.nih.gov/32202722/:
    {{Cite journal| doi = 10.1056/NEJMsb2005114| issn = 1533-4406| volume = 382| issue = 21| pages = 2049–2055| last1 = Emanuel| first1 = Ezekiel J.| last2 = Persad| first2 = Govind| last3 = Upshur| first3 = Ross| last4 = Thome| first4 = Beatriz| last5 = Parker| first5 = Michael| last6 = Glickman| first6 = Aaron| last7 = Zhang| first7 = Cathy| last8 = Boyle| first8 = Connor| last9 = Smith| first9 = Maxwell| last10 = Phillips| first10 = James P.| title = Fair Allocation of Scarce Medical Resources in the Time of Covid-19| journal = The New England Journal of Medicine| date = 2020-05-21| pmid = 32202722}} Levivich harass/hound 04:41, 26 December 2020 (UTC)[reply]

This is alarming.

See these:

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)[reply]

  • Oppose Keep politics out of Wikipedia. If you want change, write to your congressman and sentator. RudolfRed (talk) 23:45, 22 December 2020 (UTC)[reply]
But see Stop Online Piracy Act#Wikipedia blackout. Tony Tan · talk 08:32, 27 December 2020 (UTC)[reply]
  • 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)[reply]
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)[reply]
@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)[reply]

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)[reply]

Clearly mark talk pages for deceased, retired or indefinitely banned users

Formerly named “Clearly mark talk pages for deceased, retired or blocked users” – minnow Self-minnow

I feel sorry when I see users post questions to former users, and when I see the reams of automatic notices that clutter the talk pages of former users. (Example: User talk:Od Mishehu.) Both are a waste of time and resources. So I propose to add a template to any such user page that alerts both users and bots that the former user won't respond and very likely not read those automated notices anymore. In the event that a user still wants to see those automated notifications, there could be a parameter in the template to allow bots to continue posting notices. (By “user” in the previous sentence, I mean either the former user, IOW, the owner of the talk page, if they has the right to edit the page, or someone else who has a legitimate interest, such as a relative of a deceased user.) It may also make sense to stop archiving. ◅ Sebastian 10:41, 25 December 2020 (UTC)[reply]

  • Would {{Not around}} help with at least the marking part? Stopping archiving/automated messages might be more difficult, since there are all sorts of ways those happen. {{u|Sdkb}} talk 03:47, 26 December 2020 (UTC)[reply]
  • For bots, you can use {{nobots}} and Category:Wikipedians who opt out of message delivery. For users who are confirmed to be deceased, we have {{deceased}}; otherwise, if they just haven't edited for a long time, then we can use {{not around}} as Sdkb suggested. I am disinclined to add any kind of user page template just to say that a user is blocked because it would essentially be a badge of shame; see Wikipedia:Templates for discussion/Log/2019 April 17#Template:Blocked user for a recent example that got deleted because it was a net negative. In Od Mishehu's case, he already has {{sockpuppeteer}} on his user page, and anyone that clicks "edit" on a blocked user's talk page should already get a red banner above the edit window that explains that the user is blocked. Mz7 (talk) 04:06, 26 December 2020 (UTC)[reply]
    Oops, I meant indef banned, not (temporarily) blocked. trout Self-trout. For those, we already have {{Banned user}}. And the red banner is enough; it just didn't occur to me that people wouldn't read it. minnow Self-minnow ◅ Sebastian 12:32, 29 December 2020 (UTC)[reply]
  • @SebastianHelm: You can't stop archiving, once a page becomes too long MediaWiki can no longer handle it. The automated notices for deletion/discussion can be useful for talk page stalkers. — Alexis Jazz (talk or ping me) 11:55, 27 December 2020 (UTC)[reply]
    We should primarily improve the experience for the average user, and not pile up ballast just for a small group of users who might or might not find it somewhat useful. Page length: The best solution, then, would be to archive everything up to the message that announces the end of usership (that is, e.g. the announcement of death or of a ban, if it exists. Otherwise, archive everything on the page). That would avoid cases like Od Mishehu's talk page, where the one message that mattered was shoved to the archive by the weight of 10 moot automated messages. ◅ Sebastian 12:32, 29 December 2020 (UTC)[reply]
    @SebastianHelm: where the one message that mattered was shoved to the archive by the weight of 10 moot automated messages Content above the __TOC__ is never archived AFAIK. — Alexis Jazz 12:46, 29 December 2020 — continues after insertion below
    Sorry if that wasn't clear; I meant User talk:Od Mishehu/Archive17#June 2019. ◅ Sebastian 13:10, 29 December 2020 (UTC)[reply]
    Newsletters and announcements to vote on stuff are indeed useless, but for any user in good standing there is usually someone who is willing to comment when deletion of their stuff is proposed. — Alexis Jazz (talk or ping me) 12:46, 29 December 2020 (UTC)[reply]
    Good point; stuff that others may take over, such as prod notices, already account for about 50% of the text on average, so I now see the use for Wikipedia of your point that I thought was only useful for a small group. (I moved your message here to preserve context; hope that's OK with you.) ◅ Sebastian 13:10, 29 December 2020 (UTC)[reply]
    Maybe the best solution would be if we had disappearing messages (after a given time or after a given number of new sections is added). ◅ Sebastian 13:18, 29 December 2020 (UTC)[reply]

Thank you all for your answers. I now realize we already have templates for almost all cases; it's just that they often aren't used on user talk pages, but they can and have been used there, too. To summarize, we have:

The gist of my proposal therefore boils down to place those templates on user talk pages by default. Most of these already contain Category:Wikipedians who opt out of message delivery, so we already have a technical solution for my problem with the piling up of messages. The one exception is {{Banned user}}, so that should be discussed there. (Forgive me, though, for pointing to this extreme example of piled up messages.) But maybe that isn't just an on-off decision: At least for deceased users we might, per ad mortuos nil nisi bonum, only list positive messages such as the DYK messages at User talk:Halibutt. ◅ Sebastian 12:32, 29 December 2020 (UTC)[reply]

X year in Association football

In my opinion it would be better inser the finalist and the score of each final of international club competitions and delete the column of defending champions Dr Salvus (talk) 18:09, 29 December 2020 (UTC)Dr SalvusDr Salvus (talk) 18:09, 29 December 2020 (UTC)[reply]

Wiki App Idea

Hi, 


This might be a bit of a stretch or currently already underway, but...


What if there was a way you could mix the camera on your phone (like how live cameras translation of another language operates) with wikipedia's vast database of information to help people identify things of the unknown should they stumble across it and think "I wonder what that is"? 


Basically it would be like the Pokedex from pokemon which is used to identify a pokemon unknown to that person but would be of use with things on earth here today, plants, animals, items, the works! Everything! 


If a user stumbled across something completely original with no information then they could somehow be involved on the information that would pop up, 


I.E discovered by John Doe 11/11/2020 and it would bring up or update areas where they were found,


The camera would also have the geotagging function should users want to share the location of their findings, 


Anything unknown would automatically send location information to the wiki/app who could send out someone capable of investigating/studying the unknown.


A reward of some kind for original discoveries would see increased use of the app and encourage others to share the app to explore and find other things.


The app itself would cost roughly $20 to download which would really be no huge cost considering the ease of identifying things you aren't familiar with, unless it's a new discovery which would put them first inline for the information discovered after examination and analysis. 


Chemicals and probably a few other things would be tricky to identify considering it would rely on the camera talking to wiki to recognize what the user is seeing but 3d objects and most other things with distinct colors/patterns/shapes should work well, 


With roughly 7 billion people on the planet and an ad on the site encouraging people to download the new app i reckon there would be at least 1 billion users in the first 5 years based on word of mouth and the constant daily searching from users who would see the ad encouraging them to download it. 


Is this a possibility? 


Thanks for your time, 


Nathan. M

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=997070527"