Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58

Add a new type of WikiMoney

I think re-implementing WikiMoney and the related services could be cool. What if you could use WikiMoney to buy some cool things like a "Golden Barnstar" to give to exceptional work. — Preceding unsigned comment added by Education-over-easy (talk • contribs) 14:25, 11 January 2021 (UTC)

Was that really ever a thing? --Paul ❬talk❭ 15:43, 11 January 2021 (UTC)

Wikipedia:WikiMoney says it was created in 2003. By early 2006, it was marked "historical". davidwr/(talk)/(contribs) 20:22, 11 January 2021 (UTC)

I feel like the introduction of WikiMoney would be followed by WikiCorruption, WikiLobbying, and WikiBribery in today's Wikipedia. Basically, gamification of community goodwill can create perverse incentives. Ask Reddit how well their karma system has worked out. - Novov T C 08:38, 15 January 2021 (UTC)

I agree with above. However, it may help maintain Wikipedia in addition to donations. --SlatSkate (talk) 18:02, 27 January 2021 (UTC)

New modernized Main Page

I have created a more-modern version of the Main Page changing the Wikipedia:Main Page/styles.css alone.

Here is what it looks like:

You can find the css code here and the resulting Main Page here.

My primary goal of the design was to establish a clean interface by removing the closely-separated old-fashioned borders around each of the content boxes:

However after doing this, I noticed that there was little space between the primary green and blue boxes and I seeked to seperate them. Along with separating them, I also established a common separation between all boxes on the page of 8px, making the interface even more uniform and pretty.

I would like to know the community's input on what they think about the design.

Here are some possible related design questions to consider in addition to your general feedback:

1. Should the margins between the content boxes be increased further?
2. Should the shade/color of the two main boxes be changed/darkened to stand out? Without the borders they almost blend into the page.
3. Should the borders of the content boxes be rounded to be even more easy-on-the-eyes/user friendly?
4. Should the portal links to the right of the "Welcome to Wikipedia" be removed? I personally have never used them before. A search box could possibly replace it.

Lectrician1 (talk) 05:20, 21 January 2021 (UTC)

Discussion

• I'm honestly not a fan of this at all. I think the layout we have now is excellent, and that 'modernizing' it is completely unnecessary and only serves to make the Main Page look soullessly generic. At absolute best it's an unnoticable and unnecessary change, and anywhere below that it just decreases contrast (important for many people!) and makes the site look unappealingly bland and blurred. Vaticidalprophet (talk) 05:26, 21 January 2021 (UTC)
• Personally I like it, but there's nothing wrong with the current one either. See also Wikipedia:Main Page alternatives where this could be appropriate. – Finnusertop (talk ⋅ contribs) 12:05, 21 January 2021 (UTC)
• I think both this and the current page are hideous, get rid of the colors. Not to mention the poor design of having two columns continually causes us to have to make adjustments for "balance". Which everybody complains about, but nobody wants to admit that it is a problem we force on ourselves. --Khajidha (talk) 16:25, 21 January 2021 (UTC)

Is this at least a better alternative than the current version?
There have been redesign proposals in the past but have failed, mostly because multiple design/page contents were changed at once instead of small improvements like this aims to do. This caused community conflict and they failed.
Also, from editing the css of the page myself, I agree that there there are some weird design choices (such as using a table for the green and blue content boxes) and poorly coded responsive layout properties. I could of course try fixing these as part of the proposal, leaving the content layout the same to avoid conflict. Lectrician1 (talk) 17:18, 21 January 2021 (UTC)

"Is this at least a better alternative than the current version?" As I said, they are both hideous. Your question is rather like "well, would you prefer to have your left eye gouged out or your right one?" --Khajidha (talk) 17:41, 21 January 2021 (UTC)

• I don't think it'd be worth the effort trying to put this forward; it'd be a marginal improvement at best. I'm largely with Khajidha that a more fundamental redesign is needed; I've seen plenty of other language editions that have figured out something better. It'll always be an uphill battle because people become attached to the designs they're familiar with, but hopefully at some point someone will put forward something that's a clear enough improvement and argue for it smartly enough that it'll pass. {{u|Sdkb}} ^talk 18:59, 22 January 2021 (UTC)

  Possibly best to work with key Main Page stakeholders (active admins, particularly) behind the scenes to come up with something and float the idea around to get people warm to the proposal, then present the idea in an RfC. ProcrastinatingReader (talk) 15:42, 23 January 2021 (UTC)

Unlike the majority on this page, I actually think this is quite a good redesign. I like both. Unscreened. -LocalPunk (talk) 19:21, 25 January 2021 (UTC)

Improve captioning for image descriptions

As the title - improve captioning so that image descriptions are better and more accurately describe the images. LocalPunk (talk) 17:57, 23 January 2021 (UTC)

@LocalPunk: Thanks for your suggestion. When you believe an article needs improvement, please feel free to change it. We encourage you to be bold in updating pages, since wikis like ours develop faster when everybody edits. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. You can always preview your edits before you publish them or test them out in the sandbox. If you need additional help, check out our getting started page or ask the friendly folks at the Teahouse. — xaosflux ^Talk 15:55, 25 January 2021 (UTC)

Hyperlink color is too light blue and it's visually distracting

Bright Blue Hyperlink color makes reading disruptive

That is just what always strikes me when I visit. WIKI is so busy with links that the continuity of reading is broken up. A darker blue, closer to black, is more readable. I hear wiki uses darker blue for visited, or previously edited sites. Maybe that distinction could be changed and given to all-links-in-general to enhance encyclopedia readability in such a busily linked site.

Just a thought. I know when I copy and paste material, I sometimes take the time to darken the links to a darker blue so reading isn't so distracting.

UndrGrad60+ — Preceding unsigned comment added by UndrGrad60+ (talk • contribs) 03:42, 25 January 2021 (UTC)

Personally I find the shade fine but I can understand why it may not for some people. Is there an option to change the colours of text and background client-side? Or are you suggesting a server-side change? Would the server-side change be configurable client-side? I worry that a server-side change that makes links an almost-black blue may make it more difficult to distinguish from regular text, which by default is black. LocalPunk (talk) 11:11, 25 January 2021 (UTC)

@UndrGrad60+: you can set this up for yourself. Go to User:UndrGrad60+/common.css and add

a {
    color: #0000FF;
}

Where #000000 is replaced with a color of your choice. You can use this color picker to choose which color you prefer. If you want to modify the color of already-visited links, you can additionally add

a:visited {
    color: #0000FF;
}

with its own color. Vahurzpu (talk) 15:42, 25 January 2021 (UTC)

Trigger warnings

Trigger warnings should be added at the beginnings of articles or at least somewhere on the page. Avoids people accidentally stumbling across triggering content. Perhaps in the form of one of those template notice thingies that go at the top of the page? -LocalPunk (talk) 11:14, 25 January 2021 (UTC)

It would be nigh-impossible for Wikipedians, who may not share each others' societal or cultural norms, to agree on a comprehensive standard for what constitutes "triggering content". If the principle of least astonishment is properly followed, readers should generally come across offensive material only when it is expected (e.g. readers should anticipate articles on anatomy will contain images of sexual organs) and enhances their understanding of the topic, which would negate the need for warnings. There is also a general content disclaimer which explicitly warns readers that Wikipedia hosts objectionable content. (See also WP:NOTCENSORED). – Teratix ₵ 14:01, 25 January 2021 (UTC)

True. Perhaps a card with a link to the content disclaimer could be an idea? -LocalPunk (talk) 15:40, 25 January 2021 (UTC)

The problem is still which articles should have it, which is a highly subjective choice. —  HELLKNOWZ   ▎TALK 16:24, 25 January 2021 (UTC)

There'd probably have to be some sort of free-to-update list or something. -LocalPunk (talk) 19:19, 25 January 2021 (UTC)

@LocalPunk, I think you will want to read Trauma trigger. There might be some practical value in having a NSFW warning, but there is probably no benefit to a trigger warning. WhatamIdoing (talk) 02:35, 26 January 2021 (UTC)

I strongly disagree with the first paragraph of "In higher education". LocalPunk (talk) 11:35, 26 January 2021 (UTC)

The University is not engaged in making ideas safe for students. It is engaged in making students safe for ideas. Thus it permits the freest expression of views before students, trusting to their good sense in passing judgment on these views.

Clark Kerr, 1961

It might be useful to differentiate between trauma trigger and thing that makes some people uncomfortable. For example, if you saw a person stabbed to death, then you might (or might not) develop long-term PTSD as a result. Your trauma trigger, however, is statistically unlikely to be "seeing people stabbed" or "reading about people being murdered". It's likely to be something like the metallic smell of blood, or the odd motion of the murderer's head, or the food that you had eaten just beforehand. Reading about crimes or watching a violent movie might be uncomfortable (or not; some traumatized people seek out horror films[1]), but it is unlikely to be an actual, bona fide trauma trigger.

There has been talk in the past about certain kinds of content filters. Nobody should have to look at a photo of someone gouging out another person's eye or dead bodies just because Special:Random will sometimes take you to pages related to mixed martial arts or war crimes. But actual trauma triggers, rather than things that make people feel uncomfortable, are probably few and far between on wiki, and warnings for true trauma triggers are probably neither possible (how is anyone supposed to know what your personal trigger is?) nor necessarily helpful. WhatamIdoing (talk) 03:35, 30 January 2021 (UTC)

• Someone should have warned me there'd be a Trigger warning discussion on this page before I visited it, because every time I see someone proposing trigger warnings I just want to cry. EEng 21:34, 29 January 2021 (UTC)

References

mergers @ AfD (yes, again)

Moved to Wikipedia:Village pump (proposals) § mergers @ AfD (yes, again)

Yes, I know it's a perennial proposal, and yes I've read over quite a few discussions in the past and yes I do feel times are different now. Mergers often stay open exorbitantly long times . This is not practical, and the system of proposed mergers is clearly struggling with low participation and interest (not to suggest that other areas aren't). It is more effective and efficient to nominate an article for deletion if you want it to be merged. Like it or not, that would seem to be a fact at this point based on my highly unscientific day-to-day life. See, for instance, 1 and 2, where unanimous consensuses were reached in a week-- this would usually take months to a year or more if you followed the 'correct' way of proposing a merge. Currently, some users will !vote "keep: a merger should be discussed elsewhere" and I'd argue that more often than not no discussion happens elsewhere.

I'm not suggesting completely folding PROPMERGE into AfD and I'm not suggesting necessarily renaming AfD to articles for discussion, I just think it past time that we seriously consider making 'merge' a valid option to start an AfD for. Is AfD exactly booming with participants? no, but I'd argue it's higher visibility than proposing a merger, the format works just as well better, and I highly doubt the number of new merges would overwhelm the system. We could always do a trial for X months and reassess... Cheers, Eddie891 ^Talk _Work 23:22, 25 January 2021 (UTC)

• To clarify I'm suggesting that we make merge an acceptable proposal to suggest when opening an AfD, but leave Proposed mergers as a functional place where people can still file proposals if they either feel that system would work better (perhaps for a sufficiently high traffic article) or if the AfD is closed as no consensus (but, of course, not 'keep' or 'delete). This would allow most merger suggestions to get more discussion (because of higher visibility) and closed faster (time limit of AfD) and may also have the benefit of more controversial Proposed mergers getting more attention because there are more manageable amounts. Eddie891 ^Talk _Work 23:38, 25 January 2021 (UTC)

  Eddie891, I agree (as I hope everyone does) that the merge proposal system is clearly broken and needs some sort of reform. I'll leave it to others more familiar to decide whether folding it into AfD is the best approach, but I'm down to try something, and worst case scenario it fails and we return to the status quo.

  Since this is a developed, actionable proposal, you might want to move it to WP:VPR, as the idea lab isn't a place for !voting. {{u|Sdkb}} ^talk 03:18, 26 January 2021 (UTC)

  Done Eddie891 ^Talk _Work 03:43, 26 January 2021 (UTC)

WP has a problem with hundreds of pages of non-notable fake nobility

Many nations in Europe have abolished their nobility. The people who would hold this titles, or claim they would, often have articles here calling them "Prince" and "Duke."

But they are not princes or dukes, because they are not children of sovereigns or the head of a dukedom.

A few examples:

https://en.wikipedia.org/wiki/Prince_Rostislav_Romanov_(born_1985) https://en.wikipedia.org/wiki/Donatus,_Landgrave_of_Hesse https://en.wikipedia.org/wiki/Princess_B%C3%A9atrice_of_Bourbon-Two_Sicilies

I conservatively estimate there are more than 500 similar pages of people who are not notable, and only here because they claim to have royal or noble titles. It could four times this amount.

Of course a pretender could be notable because they have widespread political support for restoration. Or they could be notable as a scientist, author, etc. But rarely is this the case here.

My view is that (1) most of these articles should be deleted (2) the remaining ones the royal title like "prince" should be deleted from the article name.

Someone made a similar suggestion here in 2013:

RfC notice - proposed guideline in the Manual of Style with reference to applying "royal titles" to living members of deposed royal families

I have opened a RfC about a proposed guideline for the attribution of "royal titles and styles" to members of families whose ancestors were deposed as monarchs from various countries, often many years ago. At the moment many WP articles about these persons attribute "royal titles" to them in what seems to me a very misleading way. Please join in the discussion at Wikipedia talk:Manual of Style/Biographies "Use of royal "Titles and styles" and honorific prefixes in articles and templates referring to pretenders to abolished royal titles and their families" Smeat75 (talk) 04:45, 27 November 2013 (UTC)

Declanscottp (talk) 01:30, 26 January 2021 (UTC)

@Declanscottp, usually, our notion of notability isn't closely related to political support or real-world value. It's focused on whether you get attention from the world at large. If you are a sufficiently interesting claimant, then you get written about in the media, and then Wikipedia editors are able to write an article about you. See, e.g., Emperor Norton, who claimed a non-existent throne. If you are not interesting, then nobody writes about you, and then Wikipedia editors aren't able to write a neutral encyclopedia article about you. We aren't trying to limit Wikipedia to legally recognizable royal people. We're trying to expand Wikipedia to whatever subjects the world has chosen to pay attention to, including fake royalty with absolutely no chance of ever being placed in a position of power. WhatamIdoing (talk) 02:42, 26 January 2021 (UTC)

@Declanscottp: I hope that you wouldn't be contesting notability with every self-titled Duke, King, Queen, Prince, Count, Lady, Sir, or even Chairman. In seriousness, I think it would be best to do individual AfDs for non-notable biogs (Princess Béatrice seems a ripe candidate for deletion), but whether or not their title is "real" probably isn't the argument to go for - I wouldn't personally say that any titles are more "real" or "fake" than any others, they're all equally made up - but WP:NOTINHERITED would be relevant in a lot of these cases. --Paul ❬talk❭ 11:55, 26 January 2021 (UTC)

@WhatamIdoing: @Paul Carpenter: Responding to both these points - A small number of these people are notable for reasons beyond their fake titles. Regarding media coverage, a lot of these articles do have a few random references. But they are generally of the "Princess Betty showed up to the charity ball in a stunning dress" or "Princess Betty married Duke John." I don't think that's enough to be notable. Tons of people are written about in wedding announcements. Second, even to the extent these people are notable, the decision to title an article "Princess Beatrice" when their own government does not recognize their title is highly political: it implies the decision to abolish the nobility taken by Italy, Austria, France, etc was not legitimate. As a matter of French Law, there are no longer any French princes, dukes, etc. They are all pretenders, and should be labeled as such, not given titles. It isn't a case like Emperor Norton, whose title is obviously a joke, or actual celebrities with chart topping songs. The people who are fake royals in Europe often believe as political matters believe their republican governments are illegitimate. Giving them noble titles in their articles and article titles, and using their claimed status as a factor for notability, is making a political statement against those republican governments. We would not disrespectfully name Prince Charles's article "Charles Mountbattan" because the UK is an actual monarchy. I see articles about various French "Dukes" and "Princes" like this as equally bad as this. France, again, simply has no dukes or princes. They are both disrespectful and misleading. https://en.wikipedia.org/wiki/Prince_Charles-Philippe,_Duke_of_Anjou Declanscottp (talk) 00:42, 29 January 2021 (UTC)

On the point of names, per WP:COMMONNAME we use whatever name they would most easily be recognised by - regardless of the officialness of that title. Which is why we don't add sir to the page title for everyone who's technically been given a knighthood or whatnot.

On the point of notability i.e. whether they should have an article or not, you're quite right that "so and so wore a dress and married cousin whatshisface" does not qualify as WP:SIGCOV and if that's all the references an article has got: it should be deleted via WP:AfD. But as WhatamIdoing says, that's not much to do with the 'realness' or lack thereof of their 'title'.

--Paul ❬talk❭ 16:48, 29 January 2021 (UTC)

@Paul Carpenter: Thanks. There's a good discussion there of the sometimes tension between NPOV and most common name used. I also found this in another article "Do not use hypothetical, dissolved or defunct titles, including pretenders (real or hypothetical), unless this is what the majority of reliable sources use." https://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_(royalty_and_nobility)#Hypothetical,_dissolved_and_defunct_titles Do you think I should be "bold" with AfDs on "fake nobility" that are similar to the three examples above? I run into them a lot since I read so many articles about Western European history. Declanscottp (talk) 02:21, 30 January 2021 (UTC)

I would certainly AfD the examples you gave yes. Maybe even WP:BUNDLE each one with their parents article if they are also non-notable. --Paul ❬talk❭ 09:36, 31 January 2021 (UTC)

There should be more "in a nutshell" bulleted lists at the top of the page

I like when some articles have summaries at the top, they are really helpful, especially when I just want to get the most important information. Might be cool — Preceding unsigned comment added by TheFirstVicar4 (talk • contribs) 01:40, 27 January 2021 (UTC)

TheFirstVicar4 - sorry, are you suggesting that this should be adopted for main-space articles? Or just that it should be used more widely on essays/guides/etc? --Paul ❬talk❭ 12:48, 27 January 2021 (UTC)

I'm saying for articles, not only wikiguides. I thought that it would be helpful for slow readers like me — Preceding unsigned comment added by TheFirstVicar4 (talk • contribs) 14:32, 27 January 2021 (UTC)

Does an WP:Infobox fulfill this function? --A D Monroe III^(talk) 17:09, 27 January 2021 (UTC)

Left to right: Article body; lead; infobox; first sentence of lead; summary of first sentence of lead. EEng 21:26, 29 January 2021 (UTC)

Vacations

Some companies do mandatory vacations for employees to make sure nobody's absolutely required. I wonder if the same concept could be applied here. Or maybe it's general knowledge what the results would be. Enterprisey (talk!) 09:56, 30 January 2021 (UTC)

everything we do here is written down since writing things down is like, the only thing we can do - so I'm not sure how the bus factor could possibly apply. --Paul ❬talk❭ 21:38, 30 January 2021 (UTC)

There are various areas of wiki which would stop functioning properly, or be notably reduced in quality, if one editor left. Of course, the wiki keeps going in any case. ProcrastinatingReader (talk) 21:50, 30 January 2021 (UTC)

Recorded actions don't tell the whole story, in particular why something was done. Enterprisey (talk!) 23:55, 30 January 2021 (UTC)

It is worth noting, however, that I’m not sure this test helps. The only solution to these areas is to recruit more people to take that spot, which are functions of both our general editor recruitment efforts (from non-editors), and our ability to give existing editors permissions needed to elevate their roles. For example, there was a point last year when Primefac took a short break and BRFA grinded to a halt (and TFDH). There’s no solution to that other than more BAG (which, currently, I guess myself and Earwig are quite active), and more competent template editors with general TfD authorisations. Unblock request patrolling tends to be Yamla and another whose username escapes me. Edit filter requests pretty much rest on SoY, as most edit filter managers don’t interact with that venue, and even SoY can only do so much, so that venue is half useless. L235 was responsible for much of the ArbCom clerking I think, and still is somewhat even after election (updating templates and such). Endless list of examples like this, some of these (and others) more effected than others. No real solution to them other than train new editors, but that’s a problem in itself due to general skepticism. Most areas are documented so someone could pick them up with time, but some more obscure areas rely on unwritten conventions (TFDH work for example, and some of TFD in general). ProcrastinatingReader (talk) 00:51, 31 January 2021 (UTC)

Enterprisey, that's an interesting thought! I don't think people would go for it, but I do think there are things we could do better to help make sure Wikipedia doesn't become overly reliant on any one editor.

There are several different realms in which this applies. With regard to maintaining articles/templates/other pages, I wrote the essay Wikipedia:Build content to endure (WP:ENDURE) with my thoughts.

And then there's bots, which I think are by far our weakest link in this area. There are lots of instances where a bot operator retires, and their bot subsequently stops working, oftentimes leading to substantial damage before anyone notices. I've brought this up before and suggested some ideas, but either they aren't workable or no one has bothered to fully implement them. {{u|Sdkb}} ^talk 17:19, 1 February 2021 (UTC)

• And yet somehow we lumber forward. Once solution would be that as soon as a given editor manifests themself as high-performing and knowledgeable, we block them. Then we don't become dependent and future surprises are avoided. (Not sure themself is a word but seems to me it should go with "singular they".) EEng 15:32, 2 February 2021 (UTC)
• Breaks in some of the "big bots" (via their operators) would be the most impactful; we've got a lot of workflows that depend on this client-side work that is one-deep (for example look at this log: Special:Log/pagetriage-copyvio). — xaosflux ^Talk 15:38, 2 February 2021 (UTC)

Redirect editing guideline change proposal

Recently kicked off a discussion in Wikipedia talk:Redirect § Minimum utility threshold for redirects?. It addresses a point of debate that regularly comes up on WP:RFD and may be worth clarifying in editor guidelines. Current guidelines allow for any redirect so long as "someone" finds it useful. Interested to hear your feedback. - Wikmoz (talk) 03:55, 1 February 2021 (UTC)

Bundled cites

We currently have bundled cites like #1 in QAnon. This is arguably not good for a couple reasons:

• wrong citation count.
• unnecessary complexity in a reference.
• difficult to normalize and canonicalize for tools and data gathering.
• difficult to cite one (or a few) from the bundle somewhere else in the article.

However, it's also not great to have "Foo bar baz.[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15]". In some citation styles they use ranges on consecutive numbers above a certain threshold (e.g., [1-15]). The numbers might not always be completely consecutive, but for the one's that are they can be bundled. This would need to be done at the MediaWiki layer. Thoughts or other ideas? -- GreenC 13:49, 4 February 2021 (UTC)

At the highest level this could be achieved (a) by having the citation software aggregate/serialize consecutive citations (i.e. [1][2][3] becomes [1-3]) and (b) from there, strongly encouraging editors to not bundle citations together in one <ref></ref> set. This would be a good idea for a community wishlist project (alas the 2021 cycle just passed). Harej (talk) 16:07, 4 February 2021 (UTC)

Harej, that's a really interesting idea! One question: what would we want to happen for reused citations alongside others, such as "Foo bar baz.[47][6][48][49]"? {{u|Sdkb}} ^talk 20:24, 4 February 2021 (UTC)

We already have WP:OVERKILL for part b. Editors concerned with Lots of Citations in A Row should reduce reference groups at issue and then have the inevitable discussion. (And/or we should not cover contentious topics the way we do, which is almost always how OVERKILL situations arise.) --Izno (talk) 02:27, 5 February 2021 (UTC)

Overkill led to WP:BUNDLING which seems to say we are OK with bundling. -- GreenC 22:15, 5 February 2021 (UTC)

Because we are where the page author(s) feel they have no other option. You seek to change consensus on the point in some way... Another thing that is done is adding an explanatory footnote using {{efn}} which embeds regular reusable footnotes, usually with some explanation for each particular footnote; we might consider that as a preferable option to bundling. --Izno (talk) 06:48, 6 February 2021 (UTC)

There can be some valid uses for a bundled cite. For example, in Going steady, I bundled a cite to a paper with a cite to the errata for that paper; as a separate ref, readers might not notice that corrections had been made to the original paper. Schazjmd (talk) 20:34, 4 February 2021 (UTC)

I know this has been discussed before. I do not see a Phab task. I do not understand where you think the anchor will lead when someone clicks on a 1-15 reference. Right now the blue highlighting that comes with a selected reference is also a feature that would necessarily be lost for the references which aren't whichever reference you select as being the desired target in such a case. --Izno (talk) 02:27, 5 February 2021 (UTC)

Presumably it would jump to the first cite in the list since they are consecutive. Even better highlight them all as a block. When clicking [1-15]. -- GreenC 22:10, 5 February 2021 (UTC)

Even better highlight them all as a block. When clicking [1-15]. This is not possible. Only the targeted reference can be turned blue. Are you sure you want it to be the first? There was a big hullaballoo because AWB was reordering citations in a row (since removed). I imagine "going to the first" will have a similar issue. --Izno (talk) 06:48, 6 February 2021 (UTC)

Who's going to write the Phab task for this idea? Whatamidoing (WMF) (talk) 20:03, 8 February 2021 (UTC)

In-Article word search

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.

---

Respected Wikipedia Admins,

I would like to bring a new and essential feature to your notice which needs to be added in Wikipedia.

But before that, I would apologize for excessive trolling which I did on #wikipedia-en-help and #wikimedia-commons(Kiwi 🥝 IRC Channels). Now, I am myself exhausted after repeated trolling that I don't like to troll any more.

The feature is related to in-article search. You might have seen, when you open .pdf or .docx or .pptx file using certain apps, there is a feature through which you can search a particular word in the article.

For e.g., when you open a .pdf file using Chrome app, there is a search bar on top of the page where when you search a particular word and as you press enter, wherever the word it there in the article, it gets highlighted by a particular colour so you can refer it easily.

I am requesting to you to add this feature because I have seen there are certain users who edit articles without selecting "Watch this page" checkbox☑️. As a result, it becomes difficult to locate their edit if it is minor and the article is too big. And it might happen that those edits by the users might not be up to the marks and might need to be reverted. However, in such cases, the task becomes difficult. In such cases,we have to read entire article to locate it.

Thus, am requesting you to add a feature of word search in the article itself which will make location of a particular word easy. Secondly, it will be beneficial for readers who wish to find information on a particular topic.

It is my humble request to you to ask the respective Wikipedia developers to add this essential feature asap.

Thanks & Regards,

Akshat2103 (talk) 19:20, 4 February 2021 (UTC)

@Akshat2103: if I understand you correctly, you would like to find some text on a page, just as you can in other documents. Using your example, the ability to search the text of a PDF isn't coming from the pdf itself, but from the pdf viewer. Likewise, most modern browsers you would use to view articles already have this functionality. For example you mentioned the Chrome browser. Chrome offers "find in page" capability already, for desktop you can usually press CNTRL-F to pop open the control for it; on mobile Chrome it is usually in the "..." menu called "Find in page". Does that help? — xaosflux ^Talk 19:52, 4 February 2021 (UTC)

Indeed 😊, it worked. Issue resolved...

Akshat2103 (talk) 19:55, 4 February 2021 (UTC)

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

Turning the sidebar into a horizontal navigation menu

Many websites such as W3Schools for example have a navigation menu at the top rather than on the left. I think Wikipedia would look a lot better if it had one on top above the links. I'm not a coder, but I could sketch out what exactly the new navigation menu would look like. I would like to hear from Sdkb for thoughts on this and would like to know if it has been discussed before. Thanks, Interstellarity (talk) 20:03, 4 February 2021 (UTC)

I don't know of this being discussed before. It would entail a full redesign of Vector, which would be a very big undertaking probably better handled by the WMF as professionals (in consultation with us) than by us as volunteers. {{u|Sdkb}} ^talk 20:20, 4 February 2021 (UTC)

A user script (or gadget) may work for this, User:Blue-Haired Lawyer/Wide Skin had done some related work before, but I don't think that script is current now (and moved it to the footer- but similar concept). @Blue-Haired Lawyer: have you worked on that lately? — xaosflux ^Talk 20:29, 4 February 2021 (UTC)

Yes, it still works. The languages are moved to the footer. Most other links are moved to menus. — Blue-Haired Lawyer ^t 18:51, 5 February 2021 (UTC)

New Vector removes the sidebar in lieu of the "hamburger" icon, which makes the entire sidebar a dropdown. I presume that is preferable. (I certainly see it as so.) --Izno (talk) 02:29, 5 February 2021 (UTC)

Given the forthcoming redesign there's no benefit to this. The WMF is determined to enforce a maximum display width in the future which will mean that except on the narrowest of monitors such as using desktop view on a phone, the article text will already be surrounded by white space (see French Wikipedia for what it will look like). In that context, getting rid of the sidebar wouldn't have any benefit to readers, it would just mean even more of the page being taken up with useless white space. Bear in mind also that replacing the current always-displayed links with drop-down menus poses accessability issues both to people using screen readers or other navigation software, and to people who aren't necessarily going to be aware of how the menus work. (Wikipedia has a very broad readership of all different levels of technical knowledge and experience; you'd be surprised how many people are unaware that the hamburger icon leads to further options.) ‑ Iridescent 05:13, 5 February 2021 (UTC)

You can see the new design at w:fr:Gâteau breton. Click the ☰ or ≪ at the top by the Wikipedia globe to see how the sidebar is handled. It might be worth checking that you have your web browser set to zero zoom, if you want to see the fixed-width aspect. If you tend to zoom in a bit on a normal laptop, then it might not be visible. Note that the width depends significantly upon your device and settings. This is about 25 cm on the main designer's screen, and about 18 cm on mine (with default zoom). Whatamidoing (WMF) (talk) 20:08, 5 February 2021 (UTC)

Require editors to acknowledge WP:POLICY before saving their first edit

There are a lot of editors who are WP:NOTHERE or don't know what WP:NOTHERE means. We can't do much about those who KNOW they are here for the wrong reason, but I have an idea that will help those who are ignorant or those who might be WP:PAID but who really want to "play by the rules" but don't even know there are rules they must play by:

• Add an "I agree" check-box and link to Wikipedia:List of policies to Special:CreateAccount.
• For users who bypass that screen, add the check-box and link to the editing window but only for their first edit.
• Do the same for non-logged-in editors, except for every edit or at least every edit in a single "editing session" (i.e. until cookies are flushed or they expire).

Comments? davidwr/(talk)/(contribs) 23:06, 4 February 2021 (UTC)

This would probably lose us more positive edits than reduce the negative ones we must deal with as a matter of course. A non-starter. --Izno (talk) 02:30, 5 February 2021 (UTC)

While I can understand what you are getting at IMO the statement By publishing changes, you agree to the Terms of Use below the edit summary box would seem to cover this. I'm also not sure what difference this would make in the case of IPs since the person using it can change. MarnetteD|Talk 03:05, 5 February 2021 (UTC)

Have you ever installed a piece of software with an end-user license agreement? Do you remember what you agreed to when signing it? Did you even read it at all? Me neither. Even well intentioned people will probably just check "I agree" without reading. Gnomingstuff (talk) 00:40, 8 February 2021 (UTC)

I have to agree with the above. Without even thinking about what effect (positive or negative) this change would have, we need to realize that no one is actually going to read any warnings provided. HouseBlaster^talk 19:30, 8 February 2021 (UTC)

Should the COI edit request queue function more like RfCs?

Conflict of interest (COI) editing has long been a challenge for Wikipedia. While much of the controversy has centered on undisclosed paid editing (UPE), there also has developed an operating consensus, with support from Jimmy Wales, to encourage an "edit request" process consistent with the Conflict of interest guideline. In a nutshell, it is for responsible paid editors to suggest changes, and for volunteers to implement them if they make the encyclopedia better. This is described in more detail at WP:PSCOI and it has worked reasonably well over time, although like many request queues at Wikipedia, it often has a lengthy backlog.

As of this writing, there are more than 180 open requests, the oldest of which dates back to October. If not an all-time record, it's certainly close, especially following a period from 2018 to 2020 where the efforts of mostly a single editor kept the queue very manageable. Various suggestions have been made at the Village pump over the years to improve upon this process, including adding new parameters to the edit request template and promoting the recently-created Edit Request Wizard. I've given some thought about another way to potentially improve this system, which I've outlined below. My goal is to outline the issues as I see them here, gain some feedback, and hopefully even some support, before taking a more defined proposal to Village pump (proposals). Here's my analysis and initial suggestion:

Review of the current process

Template:Request edit has become the preferred tool for COI editors to submit requests for editor review. Currently, when an editor adds this template to a request posted on an article's Talk page, the request is added to a queue, displayed to editors in the form of a category and summary table. Reviewing volunteers who start from this queue may click on specific links to review individual requests and reply on the article's Talk page.

This template is helpful to the community by centralizing these requests, and to responsible COI editors because there's a much greater likelihood the request will be reviewed by at least one editor, eventually. It therefore provides a guideline-compliant alternative to UPE for those who are willing to take Wikipedia's rules seriously. When the process works, everyone benefits, including Wikipedia's readers.

Problems with the current process

However, the process has its shortcomings:

• The current framework is not user friendly, for reviewers or COI contributors
  • No instructions are provided, so it is difficult for either volunteers or COI editors to learn how it is supposed to work
  • No information about the request is available prior to clicking through, other than the name of the article
  • Requests are not sorted in any way, preventing reviewers from selecting topics based on knowledge, interest, or type of request
  • Protection level and Last protection log entry information is rarely useful
• As a result, requests can sit for weeks or even months before being reviewed
• It is very unusual for an edit request to receive replies from more than one editor, limiting the potential for collaborative solutions

These shortcomings have the potential to negatively impact Wikipedia as a whole:

• Readers do not benefit from the project clinging to incorrect information only because the person who pointed out the error has a COI
• Poorly formatted requests waste volunteer time; if the queue was located on a page with a link to WP:PSCOI or the Edit Request Wizard it would be easier to triage these requests for revision
• Some requests are rejected without substantive consideration, as the queue sometimes attracts editors who seem to have an aversion to COI editing. I understand and appreciate why Wikipedia editors are skeptical of COI editing. They should be! But at the same time, this process exists for a reason, and requests should be decided on the merits. Greater transparency would make these summary dismissals less common
• A cumbersome submission process and very long wait times incentivizes undisclosed paid editing

Proposed solutions for improving the process

I have lately begun to think it might be better for the edit request process to more closely resemble the Requests for comment (RfC) process, especially the way it transcludes the initial Talk page requests, sorts them into differentiated noticeboards (i.e. /Biographies), and provides a centralized noticeboard consolidating all open requests.

Whatever faults one may identify with the RfC process, it's easier to review questions at a glance, more likely to generate greater participation, and thereby reduce the burden on any one volunteer. RfCs also include designated time limits on discussion, and include invitations delivered by bots to advertise discussions to uninvolved editors. What's more, RfC statements are meant to be brief and neutral, and a revised edit request process could encourage COI editors to take a similar approach.

In this way, the RfC framework could be applied to the edit request process, where submitted requests are hosted on a centralized noticeboard and editors are given a designated length of time to discuss proposed changes and form a consensus. In many cases, requests may still be rejected, and that's fine. If a few editors quickly agree a request is unreasonable, the discussion can be closed, but at least the request was reviewed by more than one person. If editors decide a request is generally appropriate, then the article can be updated based on consensus.

My goal is to allow opportunity for reasonable requests to receive adequate consideration and implementation by neutral editors, not to influence which types of requests are accepted or rejected, nor to dictate who should be allowed to participate in discussions. I do understand that reviewing edit requests takes a toll on the Wikipedia community, i.e. the WP:BOGO analysis. But this is also why I think that making the COI request process more user-friendly and reducing the friction inherent in the current design could make things less taxing on individual volunteers.

Invitations for feedback

In addition to editors watching this idea lab page, I'd like to invite editors to this discussion who may be at least somewhat familiar with the current process because they have responded to submitted requests. Back on January 4, I reviewed the 100 most recently answered COI edit requests, dating back to December 7. Below I've compiled a list of editors who replied to those requests, and I am pinging them in the hope of getting feedback about the changes I've proposed.

This test was conducted at a good time because User:Spintendo generally stopped editing on October 26. He monitored the queue closely and responded to requests often, until recently. I would certainly welcome his thoughts as well, but by completing this assessment when I did we are able to see what the process looks like without him (much slower!).

So, here's where I solicit feedback from editors. What about the current COI request system is working? What about it is not? What thoughts and concerns do you have about making changes to the system, possibly one which looks more like the RfC process? What is valuable about the RfC process that could benefit COI edit requests? Which aspects of RfC would not be suitable for this purpose?

In closing, I'm hoping to get constructive feedback here before putting forth a more detailed proposal at another village pump page. I look forward to all responses, and I'll take them into consideration as I ponder next steps. Thanks in advance, WWB (talk) 22:55, 8 February 2021 (UTC)